Does AI drain your Mac battery?

Measured 5 to 15 October 2026 and published 16 October 2026 by Vitali Staradubau, who makes WattMate, the battery app sold on this site; the measurements were made without the app, and the page says where it was open

Three used MacBook Pro laptops from the M1 generation (one M1, two M1 Pro) running macOS 14, 26 and 27, with worn batteries at 75 to 85% of design capacity as macOS reports it, and for the repeats on 13 and 14 October the author's own M3 Max · three instruments: the chip's own power estimates (powermetrics), the battery's charge counter and the whole Mac's voltage times current (the battery pack's on battery; on the cable, the power coming in from the charger minus what goes into the battery) · every measurement below comes from our own runs, except one quoted from a GitHub issue; most of them are in a results file at the bottom, and the few that are not are listed under How we measured

The short answer: on the four MacBook Pros we measured, three from the M1 generation and the author's own M3 Max, with no MacBook Air, yes for a chat app's window answering in front, for the builds a coding agent runs and for a local model generating; the rest we could mostly read only on the chip, where it was small. The ChatGPT window answering in front, with a new essay request every 2.6 minutes, made the whole Mac draw 1.0 to 4.1 W more than the screen alone by voltage times current on the three M1-generation laptops, so the battery ran down 32 to 67% faster; hidden, it cost about a watt or less. Claude Desktop answering the same requests with its window in front cost 0.5 to 3.1 W above the screen alone by voltage times current. Builds and tests run back to back by Codex CLI or Claude Code ran the battery down 2.1 to 2.7 times as fast by voltage times current. A local 8B model generating drew 21 to 47 W of whole-Mac power by voltage times current, several times what these Macs draw with the screen alone: 0.45 to 0.58 Wh per 1,000 tokens above the screen, about 1% of a worn 50 Wh battery. An agent waiting or typing in a terminal and an agent closed mid-answer were small on the chip, which leaves out the display and the rest of the Mac; for the whole Mac, one cable series by voltage times current pointed at +0.3 to 0.8 W for a terminal with Codex streaming text, direction only. An app left idle overnight let its Mac sleep 96 to 99% of one night by the pmset log; what that night cost the battery we cannot say: each of those nights ended with the charger attached before the last battery reading.

What that means in practice, on these Macs: hide the ChatGPT window with ⌘H while you are not reading it, which in the runs that measured both took it from 1.5 to 4.1 W above the screen alone on the M1-generation Macs down to 0.6 to 1.1 W by voltage times current (for Claude Desktop we saw the saving only on the chip); with a coding agent, most of what the battery pays goes to the builds and tests it runs, 2.1 to 2.7 times the drain by voltage times current, while the agent waiting or typing added at most 0.1 W on the chip (for the whole Mac, one cable series by voltage times current pointed at +0.3 to 0.8 W for a terminal with Codex streaming text, direction only); and a local 8B model answering back to back drew 21 to 47 W of whole-Mac power by voltage times current, so on battery run it only as long as you need it.

In a test on three used MacBook Pros from the M1 generation (one M1, two M1 Pro), the ChatGPT window in front, answering a new essay request every 2.6 minutes, cost the whole Mac 1.0 to 4.1 W above the screen alone by voltage times current over 10 runs, which ran the battery down 32 to 67% faster than the screen alone (29 to 58% by the battery's charge counter, a rougher reading on some of these runs). Hidden, it cost 0.6 to 1.1 W, 11 to 19% faster, by voltage times current; the charge counter climbs back in single steps as large as this whole effect (up to 55 mAh in one step on the M1 on 11 October, during a run of builds), so read its figures for the hidden window in the tables below as rough. On the author's own M3 Max, a working Mac whose background we did not check, the window cost 4.4 to 4.6 W by voltage times current, but that Mac draws only about 3 W with the screen alone, so its battery ran down 2.5 to 2.6 times as fast by voltage times current (2.4 to 3 times by the charge counter): a per cent from one Mac does not carry over to another, and watts carry better. Build tasks launched by Codex CLI drained the battery 2.3 to 2.7 times as fast by voltage times current; on the one Mac where both agents' builds ran on battery, two runs each, Claude Code's came to about 2.1 times and Codex's to 2.3 to 2.4, but by our task log Codex got through more build tasks in each half hour (8 and 8 against 7 and 6), so this is their pace on one project, not a ranking of the agents; a local 8B model took 0.45 to 0.58 Wh per 1,000 tokens on top of the screen by voltage times current, about 1% of a worn 50 Wh battery. Claude Code typing in a terminal added at most 0.1 W to the chip, which counts only the CPU and GPU, the terminal's drawing included.

The tools people ask about, on three Macs set aside for measuring and nothing else. Every row names the instrument it came from, because the instruments disagree in ways that matter: what the per-process counter can see is a small part of what the battery pays. The three machines are named below by chip and system: an M1 Pro on macOS 27, an M1 on macOS 26 and an M1 Pro on macOS 14. The repeats of 13 and 14 October added a fourth, the author's own working M3 Max on macOS 27, which ran only the ChatGPT window series. A "run" below is one timed interval under one condition (the results file uses the same word); a "control" is the same Mac with the screen on and none of the tested apps open, measured before and after, so every figure "above the screen alone" for an app with its window in front also holds what any window in front costs: a plain TextEdit window of the same size with text in it cost about 0.6 W by voltage times current on the one M1 Pro where we measured it.

How to read the numbers. "38% faster" means the battery ran down 38% faster than on the same Mac with only the screen on; 50% faster is a third less time on battery. Watts (W) are power; joules (J, kJ) and watt-hours (Wh) are the energy a task took, and 3,600 J is 1 Wh; a worn 14-inch M1 Pro battery here holds about 50 Wh. "Chip" means the CPU and GPU alone, read with powermetrics and mostly plugged in: it leaves out the display, memory, radios and SSD, so it is not battery life. For battery life, read the whole-Mac rows: voltage times current and the charge counter, 30-minute runs on battery.

Window states. In front: the app's window on top. Hidden: ⌘H, the app runs with none of its windows on screen. Minimised: ⌘M, the window in the Dock. Covered: behind a blank TextEdit document stretched over the screen. Closed, for the terminal agents: a SIGHUP sent to the agent 90 seconds into an answer and its terminal window closed. Idle means an app open with nothing asked of it; an agent waiting at its prompt, a local model loaded with no requests and a Mac asleep overnight are each named as such. A token is the unit a model writes in, often a piece of a word.

For these three M1-generation Macs: for each condition, the range across Macs, days and repeats by voltage times current, over 30-minute runs on battery. The battery's charge counter, the other instrument, read 29 to 58, 0 to 10, 19 to 69 and 125 to 196% for the same runs; on several of them its two readings disagree (see How we measured), which is why the figure uses voltage times current. A per cent does not carry over to another Mac; the watts above the screen in the tables below carry better. The M3 Max is left off: it is another chip generation, the author's working Mac rather than a test one, and it ran only the ChatGPT series; its figures, the hours and the per-Mac figures are in the window section.

On this page: what per-app counters miss · the chat window · coding agents and their builds · local models · overnight · after closing · idle apps · browser tabs · how we measured · not measured · what WattMate shows · results data

What each tool cost, by instrument

"Faster" is relative to the same Mac with the screen on and none of the tested apps open. It does not depend on battery capacity, but it does depend on what that Mac draws with only the screen on (by voltage times current: 3.2 to 3.3 W on the M1, 5.2 to 6.0 W on the two M1 Pro, 2.8 to 3.0 W on the M3 Max), so on another Mac it will differ. "Per cent of the battery per hour" and the hours quoted further down are counted against the capacity these worn batteries report in their own logs (macOS puts their health, the share of their design capacity they still hold, at 75, 85 and 81%, 86% on the M3 Max) and are a guide for these machines, not a forecast for yours.

ChatGPT's own processes were charged 0.2 to 0.4 W. The whole Mac paid 1.0 to 4.6 W more by voltage times current, across four Macs

While ChatGPT streamed answers with its window in front, the per-process energy counter in the macOS kernel, the one WattMate reads, charged ChatGPT's processes 0.21 to 0.36 W. Activity Monitor's Energy Impact is a score built on the kernel's per-process accounting; which counters it weighs we did not check. Over the same 30-minute runs the whole Mac drew 1.0 to 4.6 W more than it did with the screen alone by voltage times current. On the three M1-generation Macs that was +1.0 to 3.4 W by the battery's charge counter and +1.0 to 4.1 W by voltage times current, 5 to 13 times what the per-process counter shows; on the M3 Max, +4.01 to 5.35 W and +4.43 to 4.60 W, 16 to 21 times.

Where does the rest go? In the runs of 11 and 12 October the CPU and GPU together account for only +0.5 to 0.6 W of it, and that figure already includes the work WindowServer does on their behalf. The remaining 1.2 to 2.6 W by the charge counter (1.0 to 3.5 W by voltage times current) are seen by neither the chip counters nor the per-process counter. We did not measure what they are made of, so we name no culprit.

Claude Desktop's processes were charged even less, 0.06 to 0.11 W, while the whole Mac paid 0.9 to 4.0 W above the screen by the charge counter (0.5 to 3.1 W by voltage times current) with its window in front. Any tool that adds up per-process energy, ours included, sees the small number. The battery sees the whole rise while the window was in front, including what any window on screen costs; which parts of the Mac it went to we did not measure.

ChatGPT in front costs the whole Mac watts; on two M1-generation Macs, one day each, the window just being on screen was a third to a half of it by voltage times current. Hidden, most goes away

Over all 10 runs, 11 to 14 October, the window in front made the battery drain 32 to 67% faster than with the screen alone by voltage times current, about 24 to 40% less time on battery, and 29 to 58% faster by the charge counter, about 23 to 37% less time; by the counter that is 2.0 to 6.7% of the battery per hour on top of the screen. Run by run, in the first pass: on battery, with each essay request in a new temporary chat, 2.6 minutes apart, the ChatGPT window in front made the battery drain 43 to 67% faster than with the screen alone by voltage times current, and 38 to 53% faster by the charge counter: +45% and +53% by the counter on the M1 Pro running macOS 27 across two days (+49% and +67% by voltage times current), +51% on the M1 (+45%; one tick later the counter reads +13%, see How we measured), +38% on the M1 Pro running macOS 14 (+43%). That is about 30 to 40% less time on battery by voltage times current and 27 to 34% by the counter, or, by the counter, 3.4 to 6.3% of the battery per hour on top of what the screen costs. Four runs of 30 minutes with 12 answers each, three Macs, the macOS 27 machine twice, in one fixed-order pass on 11 and 12 October. The top of the range (+53%) is the run on the author's own account on 12 October; the other three, 38 to 51%, ran on the test Macs' own account. Both ChatGPT accounts were on the same tier, so the tier does not explain the gap. A repeat on 13 October on the macOS 27 machine, on the author's account and in ABBA order (control, front, hidden, hidden, front, control, so that drift cancels), gave +58% and +54% (+53% and +56% by voltage times current, below), which makes it 38 to 58% by the counter and 43 to 67% by voltage times current over six runs. The answering runs of the split series on 14 October (below) mostly read lower than each Mac's own earlier runs: +38 and +55% by voltage times current on the M1 Pro, against 49 to 67% before, and +32 and +41% on the M1, against 45% (by the counter +43 and +43% on the M1 Pro, against 45 to 58% before, and +29 and +32% on the M1, whose earlier counter reading is the rough one).

Hidden with ⌘H, the same traffic cost 0 to 10% by the charge counter (+10% and 0% on the M1 Pro with macOS 27, +7% on the M1, +7% on the M1 Pro with macOS 14), 11 to 18% by voltage times current. The two instruments disagree here more than anywhere else on the page. In that pass the hidden run always ran right after the front run, and the charge counter rebounds upward for a while after a heavy load ends, which would make the hidden run look cheaper than it was; voltage times current, a snapshot of the current that the battery controller publishes about once a minute, carries nothing over from one minute to the next. The ABBA repeats below were built for exactly that question. The 13 October repeat on the macOS 27 machine gave +3% and +6% (12 and 19% by voltage times current), which makes it 0 to 10% and 11 to 19% over six runs.

Claude Desktop with its window in front (its everyday behaviour on a working Mac is on the Claude page) came in at 16 to 52% faster by voltage times current and 19 to 69% by the charge counter: +69% and +35% by the counter on the M1 Pro with macOS 27 (+52% and +26% by voltage times current), +28% on the M1 (+16%), +38% and +19% on the M1 Pro with macOS 14 (+32% and +26%), or 1.8 to 8.1% of the battery per hour. On the macOS 14 machine, 2 to 3 of its 12 prompts fell in our "unsure" band for whether an answer arrived, and the counter's lower bound (19%) stands on that run; the lower bound by voltage times current (16%) is the M1's run, where 11 of 12 read in that band, which on that machine is what a Claude answer looks like (see the audit note under "How we measured"). For Claude Desktop that energy audit was the only check: the byte count that judged ChatGPT's answers from 13 October was never run on Claude. One possible reason for the spread is the length of the answers, which we did not log, so it stays untested; in watts the same runs read +0.5 to 3.1 W above the screen by voltage times current. On the 60 Hz LCD of the M1 the Claude window drew 0.07 W on the GPU against 0.12 to 0.42 W on the two mini-LED M1 Pro machines, a comparison between Macs that Apple's manual for powermetrics warns against; we did not separate refresh rate from chip from panel, and on mini-LED the cost also depends on what the window shows.

Hours assume you did only that, from a full charge, on these worn batteries; the capacity comes from the battery's own log and differs from the percent gauge by up to 9%, so read hours and per-hour figures as a guide within about 10%. The controls themselves moved between runs (8.2 to 8.9 hours on the macOS 27 machine), and every hour figure carries that spread too. The two "faster" columns are ratios of two drains on the same Mac and do not depend on capacity; hours and per-hour figures come from the charge counter, except the last column: the M1's counter is the rough one (see How we measured), so its hours are given by voltage times current as well, against the same capacity. In the fixed-order pass of 11 and 12 October there is one run per condition per Mac and day, so those ranges are spreads across Macs and days; the ABBA repeats of 13 October (ChatGPT on the macOS 27 machine, both agents' builds on the macOS 14 one) add two runs per condition on one Mac, and the split series of 14 October add two answering runs each on the macOS 27 machine and the M1. Where one condition ran twice on the same Mac and day, the two runs differed by up to 1.0 W by voltage times current (the answering runs of 14 October on the M1 Pro, +2.25 and +3.25 W), so read a gap of less than about a watt between single runs as inside that spread, and every range here as what these runs gave.

Repeated in ABBA order, and on an M3 Max: watts by voltage times current held, percentages did not

Two objections to the pass above were fair: one run per condition, and "hidden" always right after "front". So on 13 October the macOS 27 M1 Pro ran ChatGPT again in ABBA order (control, front, hidden, hidden, front, control; 30 minutes each, 12 prompts per run, the author's account), and the author's own working Mac, a 14-inch MacBook Pro with M3 Max on macOS 27, ran the same series twice, overnight from 13 to 14 October and again in the early morning of 14 October. How to read them was written down before the runs (the rule that each run's first prompt is not judged was added after the M1 Pro's runs and before the M3 Max's; on the M1 Pro every run passes either way): a run counts if at least 10 of its 11 judged prompts show an answer by the bytes ChatGPT received; a run whose two charge-counter readings (see "How we measured") differ by more than 10 points is read by voltage times current; and if the first hidden run reads lower than the second by more than the two front runs differ, that is the order tail, and the hidden figure is the second hidden run.

"Faster" by the battery's charge counter, watts above the screen by voltage times current. The M3 Max's battery is at 86% of design capacity as macOS reports it, after 617 cycles. On 14 October the first control started right after the charger came off, and the counter under-read its first 5 minutes; with a steady control the +197% would be about +182%, and by voltage times current that run reads +152%. The 24.7 hours come from the same control. Every run of these two series, including the 3 that failed the answer rule and one extra front run with WattMate open, is in the CSV; the first M3 Max series of 13 October, spoiled by the byte counter, is not (see What we threw out).

In watts the two Macs agree on the shape and differ in size: by voltage times current the ChatGPT window in front cost the M1 Pro 3.1 to 3.3 W above the screen and the M3 Max 4.4 to 4.6 W, on macOS 27 (27.0.1 and 27.0), the same account and ChatGPT version, at the same brightness setting on 14-inch mini-LED displays of two generations (the same setting is not necessarily the same light output). In per cent they do not agree at all, +54 to 58% against +142 to 197%, partly because the M3 Max draws only 2.8 to 3.0 W with the screen alone and the M1 Pro 5.8 to 5.9 W, and partly because its window cost more watts. So a "per cent faster" from one Mac does not carry over to another, ours included. Watts above the screen carry better, and even they differ between these two Macs by more than a watt by voltage times current; by the charge counter the gap swings from 0.6 to 2.4 W between individual runs.

Hidden, the window cost the M1 Pro 3% and 6% by the charge counter (0.7 and 1.1 W by voltage times current); its two hidden runs differed by exactly as much as its two front runs, so by the rule there was no order tail. On the M3 Max the first series' hidden runs failed the answer rule, 8 and 9 answers of 11: on that Mac an answer and silence read close together (in one check the app's background traffic alone came to about 69 KB over the same interval and an answer to about 123 KB), and a connection that closes can cut an answer's count short. In the repeat they passed, and by the rule the order tail counts as shown (15.8 points against 3.5, where the 3.5 comes from a front pair one of whose runs failed the answer rule), so the hidden figure is the second hidden run: +33% by the charge counter, 0.8 W by voltage times current (had the rule not fired, the mean of both hidden runs would read +25% and 1.1 W). On both Macs of the repeat, the M1 Pro with macOS 27 and the M3 Max, hiding took the window from 3.1 to 4.6 W above the screen down to about 0.7 to 1.1 W by voltage times current; on the M1, with a 60 Hz LCD and a smaller chip (which of the two matters we did not separate), the window cost less to begin with, 1.5 W in front against 0.6 W hidden on 11 October.

Two things about the instruments turned up only after the ABBA repeats, and both make small readings fragile. The charge counter carries part of one run into the first 2 to 5 minutes of the next: right after a front run, the counter showed the first 5 minutes of a hidden run on the M3 Max draining −9 and +3 mAh, against 22 to 28 mAh in each later 5-minute span. And the battery current behind voltage times current updates about once a minute, so a 30-minute run is about 30 snapshots, and the few that land on the moment a prompt is sent (the hidden window comes forward for a few seconds to take it) can move a small reading by tenths of a watt. Read without each run's first 5 minutes, the two instruments agree on the front runs to within 0.4 W and still differ on the hidden ones by up to half a watt. Read the hidden figures as "about a watt or less", not to the per cent.

In absolute terms, by voltage times current at about 70% brightness: the whole Mac with the screen on and none of the tested apps open drew 3.2 to 3.3 W on the M1, 5.2 to 6.0 W on the two M1 Pro and 2.8 to 3.0 W on the M3 Max; with the ChatGPT window answering in front, 4.3 to 4.8 W, 7.5 to 10.1 W and 7.3 to 7.4 W; with Claude Desktop answering in front, 3.8 W on the M1 and 6.8 to 9.1 W on the M1 Pro machines. For comparison, a comment of 26 September 2026 on anthropics/claude-code issue 94003 reports, on a 16-inch M3 Pro on battery (macOS 27.0, Claude Desktop 2.7032.0), that a visible Claude Desktop window with a Claude Code agent working in it cost about 11 to 13 W: 15.7 to 18.9 W against 5.3 to 5.6 W with the window hidden, read from the Mac's SMC power keys as system power minus the display backlight. Our Claude Desktop figures are a fresh chat on the three M1-generation Macs; we did not measure an agent working in the app's window, a long thread on battery, or any other Mac.

What the runs so far cannot split by themselves: the control has none of the tested apps open, so the watts above are the window being on screen and the answer streaming in it, together. A separate series on 14 October split them, and the M1's part of it was repeated that evening.

The window on screen against the answer in it: the two shared the cost on the M1 Pro with macOS 27, and on the M1 by voltage times current

On 14 October the macOS 27 M1 Pro and the M1 ran one more series: control, static window, answers, answers, static window, control, 30 minutes each on battery, with a 4-minute warm-up before every run. "Static" means one essay request sent during the warm-up and finished before the measured half hour began, so for 30 minutes the window in front showed a finished essay and nothing in it moved; "answers" is the same window with a new essay request every 2.6 minutes. macOS was in dark appearance on both Macs, as checked that morning; the M1's evening repeat did not record it. How to read it was written down before the runs: if the answers above the static window come to at least two thirds of what the window in front cost above the screen in the earlier runs on the same Mac (four runs, 11 to 13 October, on the M1 Pro; one, 11 October, on the M1), it is mostly the answer you pay for; at most a third, mostly the window; in between, both. The M1's first series that morning failed (below) and was repeated in the evening.

So on both Macs, one day each, in dark appearance as checked that morning, the two shared it. On the M1 Pro, with its mini-LED display (ProMotion, adaptive up to 120 Hz; which setting it was on we did not check), a finished essay sitting in the window in front cost 1.3 to 1.4 W above the screen by voltage times current (1.2 to 1.3 by the charge counter), and the answers streaming into it added about as much again. Both instruments read the same way, and so do the edges of the October range (0.35 to 0.48 of it). Against the October runs rather than the same day, the static window comes to 0.40 of them and the answers to 0.42: the answering runs of 14 October cost about 0.6 W less than October's, so the two parts do not add up to the October whole. On the M1, with a 60 Hz LCD and a smaller chip, everything was smaller: the still window cost about half a watt by voltage times current and the answers added 0.7 W, 0.48 of its October run; that reference is a single run, and by the charge counter the M1 cannot be read under the rule. Its answering runs that evening, +1.04 and +1.34 W, read below that October run (+1.48 W), as the M1 Pro's did on average (+2.75 W against +3.36 W). By voltage times current the still window alone came to 0.40 of the October whole on the M1 Pro and 0.33 on the M1, and to 0.49 and 0.41 of the same day's answering runs: a third to a half on these two days; the two answering runs on the M1 Pro differed by 1.0 W by voltage times current, so take it as a first split, not a fixed share. On the chip the answers are the larger part on both Macs, but most of the whole-Mac cost of both sits outside the chip counters, in parts of the Mac we have no separate reading for. The answer rule passed in every answering run (13 of 13 on the M1 Pro, 12 of 13 on the M1), and by voltage times current the second static run read below the first on each Mac, so by the rule there was no order tail (on the M1 the charge counter, which is not read there, had the second static run 0.14 W above the first). Static means a still window with text in it, not an empty one; a blank ChatGPT window we did not run. WattMate was open on the M1 Pro through the series, at 0.9 to 1.5 mW by our collector in every run, control included, and closed on the M1.

The M1's first series, that morning, did not measure what it was meant to. By the rule written before the data its runs passed (11 and 12 answers of 13 by the bytes ChatGPT received), but a second instrument says the window was not drawing them: by the per-process counter, ChatGPT's renderer process (ChatGPT for Mac draws its chat with a built-in Chromium engine, and this is that engine's drawing helper, Codex (Renderer) inside ChatGPT.app, unrelated to the Codex CLI) used 0.003 W in the answering runs, against 0.25 W on the M1 Pro, and by powermetrics the GPU sat at 0.58 to 0.59 W for the whole of every ChatGPT run, the static ones included, against 0.05 W on the same M1 with the window in front on 11 October. ChatGPT also updated itself between the first static run and the first answering run (26.1007.30912 to 26.1007.71326). We left that series out of the reading and kept its runs in the CSV with the reason. Read by the rule anyway, it would have said that you pay for the window and not for the answer: the still window and the answering runs alike read 1.7 to 1.8 W above the screen by voltage times current. The same sign dropped a run on the macOS 14 machine on 12 October. The evening repeat ran with ChatGPT's updater off and two more rules written before its data: a run with answers counts only if ChatGPT's renderer used at least 0.1 W, and a static run only if the renderer drew the answer during the warm-up (above 0.05 W) and the GPU stayed under 0.2 W. Every run passed: the renderer used 0.19 to 0.20 W in the answering runs and the GPU 0.04 W in the static ones. What the split looks like on the M3 Max stays open.

A plain text window set to the same frame cost the M1 Pro less than half of what the still ChatGPT window did

Was that 1.3 to 1.4 W (by voltage times current) for a still window ChatGPT's, or what any window with text costs on this screen? That evening the macOS 27 M1 Pro ran control, still ChatGPT window, TextEdit window, TextEdit window, still ChatGPT window, control, 30 minutes each on battery after a 4-minute warm-up. The TextEdit window was set to the frame ChatGPT's window had (1,090 by 760 points, read from ChatGPT's window in each warm-up; TextEdit's own frame was not read back), holding a ready essay on the same subject (1,427 words, set to 16-point type; ChatGPT had been asked for about 1,500 words, and the length of its answer was not recorded), in dark appearance as checked that morning (the evening runs did not record it), and nothing moved in it for the measured half hour. How to read it was written down before the runs: if the TextEdit window cost at least two thirds of the ChatGPT window above the screen, you pay for a window on screen and not for ChatGPT; at most a third, the ChatGPT window costs more than an ordinary one; in between, part of each. Voltage times current is the main instrument, and if the two disagree the page names both.

By voltage times current it is in between: the TextEdit window cost about 0.6 W above the screen, 0.45 of the still ChatGPT window's 1.35 W, so the still ChatGPT window cost about 0.75 W more than this TextEdit window, and the two did not show the same picture (another essay, type and spacing set differently), so 0.75 W is the gap between these two windows, not what ChatGPT adds to any window. By the charge counter the TextEdit window comes to 0.25 of ChatGPT's, which by the same rule reads as the ChatGPT window costing more than an ordinary one; the counter is the second instrument by the rule, and its two TextEdit runs read +0.04 and +0.67 W, so its reading is the weaker of the two here. Both instruments put the still ChatGPT window above a plain one, by 0.75 W by voltage times current or about 1.1 W by the counter. On the chip the TextEdit window read 0.01 W above the control against 0.14 to 0.15 W for the ChatGPT window; the rest of the difference sits outside the chip counters, and what it is made of we did not measure. One Mac, one evening, dark appearance as checked that morning; the two apps set text differently (type size and line spacing), and ChatGPT's own processes were charged 0.015 to 0.016 W while nothing moved. WattMate was open through the series at 1.0 to 1.3 mW.

On the chip, covering Claude with another window did not make it cheaper

A second series looked at four window states with the chip counters only: 8-minute runs, two prompts per run, two repeats per state in ABBA order (condition A, then B, then B, then A, so that drift cancels), on battery, repeated on a second day; every figure is the mean over the whole 8-minute run. In front, the two apps added +0.13 to 0.58 W to the chip while answering. Hidden, +0.05 to 0.11 W. Minimised, +0.05 to 0.08 W. Hiding or minimising removed between half and nine tenths of the chip cost (51 to 87% by Mac and day, about three quarters on average; the 51% is the M1 on 8 October with ChatGPT, where the front answers fell in the unsure band, and runs with confirmed answers gave 61 to 87%).

Ranges over three Macs on 8 October and two on 10 October; mean of two repeats per cell. The prompt is always sent with the window in front; 2 seconds later the window is hidden, minimised, or covered by a blank TextEdit document stretched over the whole screen (not macOS full-screen mode). Several 8 October runs, for both apps, in front and behind another window, had prompts in the unsure or none band; the per-prompt audit is in the CSV.

Covering Claude with another window did not make it cheaper in these 8-minute runs: in 4 of the 5 Mac-days it read higher behind the other window than in front, and behind it read +0.21 to 0.88 W, the covering TextEdit document's own cost included; whether Claude registered that it was covered we did not check. ChatGPT behind another window was cheaper than in front, +0.18 to 0.33 W. On the chip, then, hiding or minimising saved for both apps, and covering saved for ChatGPT but not for Claude; of these states only ChatGPT hidden was measured for the whole machine, in the battery runs above.

On the chip, a 12-message thread did not get steadily more expensive per message

The thread: 12 requests for essays of about 1,500 words each, 2.6 minutes apart in one chat, with the window in front, on the cable, chip counters only; each message is scored by the chip's mean power in the 140 seconds after sending, so these watts are not comparable with the 8-minute run means above. The cost per message did not climb as the thread grew: the mean of the last three messages against the first three ran from 64% lower to 34% higher, and the +34% rests on a single 1.07 W outlier. From one message to the next the cost jumped by up to 2.5 times. ChatGPT sat at 0.4 to 0.7 W per message, with one message at 1.07 W, Claude at 0.17 to 0.5 W, with Claude's first messages on 9 October up to 1.0 W. Claude's three threads on 9 October started expensive and dropped after the first 1 to 4 messages; on 2 of the Macs they drifted up again toward the twelfth, all inside that jump range. On 12 October it was flat from the first message to the last. Two days, three Macs the first day and the M1 the second. We did not measure the whole machine during the thread, so this series says nothing about whole-machine power in a long thread.

An agent waiting or typing barely registers on the chip. The builds it launches are where the energy goes

An agent waiting at its prompt added 0.00 to +0.03 W to the chip: Claude Code in three terminals, three Macs, two days. The agents' own processes drew 0.001 W or less (Codex, Copilot, Antigravity, measured on 6 October). Claude Code writing an answer added +0.03 to 0.10 W to the chip depending on the terminal. Codex writing an answer was charged 0.024 to 0.027 W on its processes; we did not measure Copilot writing. The model runs in the cloud; on the Mac, what you see in the terminal is text arriving, and the commands the agent runs locally are a separate bill, below.

Give the same agents a task with builds and tests and the picture changes: most of the energy goes to the builds and tests the agent decides to run, not to the agent's own process. The task: a C project with three or four planted bugs, where the agent runs make test itself (10,240 tests), two tasks per run, on the cable. Each task cost 0.4 to 1.7 kJ of chip energy, 0.1 to 0.5 Wh; the battery pays more than the chip, so that is at least 0.2 to 1% of a worn 50 Wh battery, across three Macs and four days. Codex's own processes drew 0.024 to 0.027 W while it typed and Claude Code, with its terminal, at most 0.1 W on the chip; over a task of a few minutes that is a few tens of joules at most, so most of a task's 0.4 to 1.7 kJ, by that subtraction rather than a split by process, is what the agent launches, the compiler and the test run, the same shape Xcode's builds have on this site. It is a teaching task, not an hour of real work: what real work costs is however many builds and test runs the agent decides to launch.

Chip CPU+GPU over the whole run minus control, on the cable. The 372 J lower bound for Claude Code is a run on the M1 Pro with macOS 27 where both fixes were left incomplete; pairs where both fixes were complete ran 651 to 1,350 J. Ranges, not means, on purpose: an incomplete fix is less work and less energy.

On battery the builds are what you feel. With Codex running build tasks back to back, the battery drained 130 to 174% faster than with the screen alone by voltage times current, so 2.3 to 2.7 times the pace (125 to 196% by the charge counter): 12.9 to 15.9% of the battery per hour on top of the screen. From a full charge that is 3.6 to 5.1 hours of continuous builds against 8.2 to 15.2 hours of the screen alone on the same three Macs by the charge counter (seven 30-minute runs, 11 to 13 October; on the M1, whose counter is the rough one, 5.3 hours against 14.9 to 15.3 by voltage times current). On 13 October the M1 Pro with macOS 14 ran both agents' build tasks back to back in ABBA order: Claude Code's drained it 112 and 118% faster by the charge counter, Codex's 134 and 158%; by voltage times current 115 and 114% against 137 and 130%, or 6.2 W and 7.0 to 7.4 W above the screen; by our task log Codex finished 8 and 8 build tasks in these runs against Claude Code's 7 and 6, so this is their pace on one project, not a ranking of the agents. From a full charge, by the charge counter, those drains come to 4.7 to 4.9 hours of Claude Code's builds and 4.0 to 4.4 of Codex's against 10.1 to 10.6 hours of the screen alone on that Mac. During the Codex runs the CPU alone sat at 3.4 to 4.4 W on the chip counters, during Claude Code's at 2.9 to 3.0 W.

Four agents at once, on the chip: no difference we could resolve per task for Claude Code, about a fifth more for Codex, both inside the day-to-day spread

Four copies of the same agent on four copies of the project, launched together, cost 546 to 1,081 J per task against 372 to 1,350 J for one agent alone, which is inside one agent's day-to-day spread. Codex averaged about 795 J per task in a group of four against about 657 J alone in the same series, 21% more; Claude Code about 721 J against 752 J, 4% less, and since those means include the incomplete fixes (a third of Claude Code's single runs against a fifth of its copies), read the Claude Code comparison as no difference we could resolve. The four finished together in 4.4 to 7.6 minutes, between 0.8 and 2.5 times the time of a single task on the same Mac, 1.8 times on average. Three Macs, 10 to 12 October. On the chip, per attempted task with incomplete fixes included, running agents in parallel showed no difference we could resolve for Claude Code and about a fifth more for Codex, which is inside one agent's own day-to-day spread but may be real: four tasks cost 4 to 5 times one, and you pay per build, whoever launched it. What four at once do to the whole machine on battery we did not measure.

Cursor's agent inside the IDE costs tens of joules on the chip, and hiding the window saved roughly half

Cursor's agent in the agents window cost 26 to 104 J of chip energy per edit with the window in front and 16 to 27 J with the window hidden right after sending, counted in the 70 seconds around sending. The same small fix without any commands (a Python file with four bugs) cost Claude Code without a user interface 3.6 to 6.3 J per task, counted in one window from 10 seconds before its first task to 60 seconds after its last (its three tasks ran back to back, so a separate 70-second window per task would count the same work up to three times). Cursor's is 4 to 27 times that with its window in front and 2.5 to 8 times with it hidden, on the same Mac; that sets an IDE with its window and its default model against a terminal agent on Sonnet with no window, so the ratio compares the two setups, not the agents, and it is still tens of joules on the chip, at least 0.01 to 0.06% of a battery of about 50 Wh. Hiding Cursor while its agent works made each edit 1.7 to 3 times cheaper on average per Mac, and on the M1, where we checked, the Cursor processes did the same work either way, which points at drawing the window. Cursor's agent did its work almost entirely outside a process of its own: on 2 of the Macs Cursor started a small cursor-agent worker with the first task, and the per-process counter charged it almost nothing; the work shows up in Cursor Helper (Renderer) and Cursor Helper (Plugin), with the model in the cloud. Three tasks per state on three Macs, 11 and 12 October; on the M1 Pro with macOS 14, 2 of the hidden tasks never touched the file, most likely a usage limit. Cursor open and waiting, with the agents window and no folder, added +0.03 to 0.04 W on the chip in these runs (+0.03 to 0.05 W in the idle series of 10 and 11 October).

On the chip, the terminal changed the cost by hundredths of a watt

People blame iTerm2 or Ghostty when an agent eats battery. On the cable, with Claude Code writing three essays in 8 minutes, the chip cost by terminal was small and consistent across two days and three Macs:

An empty iTerm2 window with no agent read from 0.007 below to 0.018 above the control, an empty Ghostty window 0.000 to 0.011 above it. In each of the 4 Mac-days with a usable iTerm2 run, iTerm2 read highest of the three while text streamed, and the whole difference on the chip is a few hundredths of a watt. All of it was on the cable. On battery iTerm2 3.7.3 switches its GPU renderer off unless told otherwise (a default in its source code, which we did not check on the test Macs), so its standing on battery may differ; we did not measure terminals on battery. What a visible terminal costs the whole machine on battery we did not measure; one cable series with Codex streaming on 7 October (three Macs, a once-a-minute snapshot) pointed at +0.3 to 0.8 W above the control, and we take that as direction only. On 8 October every iTerm2 run on the two M1 Pro machines had to be thrown out (iTerm2 hung on a permission prompt), and so was the empty-Ghostty run that iTerm2 spoiled; the Claude Code runs in Ghostty that day were kept. The iTerm2 writing figure therefore rests on 4 runs rather than 6, and its waiting and empty-window figures for those two Macs come from a repeat the same evening.

The kernel's per-app accounting tells a different story. In it the agent, the compiler and tests it launched in our runs and the drawing of its text interface all belonged to the terminal app's group, which is how our collector saw them, and an app list built on that accounting would show them under Terminal, iTerm2 or Ghostty. We read the grouping with our collector, not from Activity Monitor's own screen, and how its Energy Impact score weighs them we did not check. The agent itself, on its own processes, is 0.001 W or less while waiting at its prompt and about 0.03 W while typing; the builds it launches ran at 3.4 to 4.4 W of CPU on the chip counters during the Codex battery runs. In that accounting the terminal is the name on the bill; its own drawing is a few hundredths of a watt of it on the chip, and the builds are most of the rest.

A local model is a different league: about 1.8 J per token for the whole Mac, and nothing we could resolve while it is loaded with no requests

Ollama 0.40.0 with llama3.1:8b, generating answer after answer of about 1,000 tokens with a 10-second pause between them, on battery: 1.6 to 2.1 J per token of whole-machine energy above the screen by voltage times current, about 1.8 in the middle of the five readings. llama3.2:3b came in at about 0.9 J per token on the M1 (the macOS 14 machine's reading for the 3B model is unreliable, see the table). The 8B model ran on three Macs, the 3B on two. On the M1 we repeated the 8B model on 13 October in two 30-minute runs with a control between them, long enough for the battery's charge counter: 1.98 and 1.87 J per token by the counter (1.73 and 1.65 with the counter read a tick later), 1.71 and 1.81 by voltage times current, 0.82 and 0.80 on the chip. Read the counter figure as probably high: after each 8B run the counter climbed back by up to 153 mAh in one step, between runs, where no measurement window sees it.

On battery, 8 October. The 3B reading on the macOS 14 machine is unreliable because voltage and current are sampled once a minute, and a load that runs 20 seconds and rests 10 defeats a 1-minute snapshot: 49 W for the 3B model against 36.5 W for the larger 8B on the same Mac is most likely the sampler, not the model. The chip column does not have that problem. Watts are averaged over the whole run, pauses included, so J per token is not the watts divided by the generation speed: it is the energy above the screen-only control over the run's 600 seconds, divided by the tokens actually produced in the run, with an answer that straddles the start or end counted by its share. The last two columns set the run's whole-Mac draw against the same series' screen-only control, both by voltage times current, and divide the battery's capacity from its own log by that draw: how long a full charge would last answering like this, the 10-second pauses included, on these worn batteries.

The M1 Pro generated the 8B model twice as fast as the M1 (23.8 against 12.4 tokens per second) and drew about twice the power while doing it, 36 to 47 W of whole-machine power averaged over a run with pauses, around 50 W during generation itself on the cable, against about 21 W on the M1. Per token the two chips came out nearly even by voltage times current: the M1's 1.87 J fell between the two M1 Pro readings, 1.63 and 2.11. The chip counters read 0.92 against 0.95 J, though Apple's manual for powermetrics warns against comparing its figures between devices. The two M1 Pro machines, at the same 23.8 tokens per second and nearly the same chip power, read 47.4 and 36.5 W of whole-machine power, a 30% gap. The percent gauge, a second reading that is not a snapshot, also put the macOS 27 machine higher (about 51 against 41 W, from the lab notes), so we cannot blame the battery current's update rate alone, although an answer with its pause took about a minute, close to how often that current updated; the two machines differ in macOS, battery wear and state of charge, and each ran a single run. That gap is the whole width of the 1.6 to 2.1 J range. The CPU and GPU counters account for about half of the machine's energy per token (45 to 58% in the 8 October runs, 41 to 48% in the 13 October ones on the M1); the rest lands outside those counters, and we did not measure what it is made of.

In plainer units: 1,000 tokens from the 8B model cost 1.6 to 2.1 kJ, 0.45 to 0.58 Wh, or about 1% of a worn 14-inch battery of around 50 Wh on top of the screen.

A question we could not find a published number for: what does a model that is loaded with no requests cost? Nothing we could measure. With llama3.1:8b held in memory for an hour and no requests (keep_alive -1, which keeps a model loaded; Ollama's FAQ on 14 October 2026 gives 5 minutes as the default before it unloads one, a setting we did not check on 0.40.0), the whole Mac read 0.04 W below the control on the M1 and 0.01 W below on the M1 Pro with macOS 14; the Ollama server with no model loaded, half an hour, read 0.06 W below and 0.02 W above. A reading below the control is drift in the machine or the instrument, not a saving and not negative power; on the M1 it is larger than the spread between that Mac's own controls, which we cannot explain. With the model loaded both readings were below the control; across all four, none is more than 0.02 W above it. One instrument, voltage times current on the cable, one night, 7 to 8 October, about 60 snapshots an hour on a flat load; the control runs around the hour-long readings differed by up to 0.04 W. The first 10 minutes right after generation did show +0.14 to 0.26 W before the machine settled. On an otherwise idle Mac, then, a loaded model cost nothing we could resolve over an hour. What it costs when the rest of your work competes with it for 16 GB of memory we did not measure. LM Studio and MLX were not measured, and the run on the macOS 27 machine is a single 10-minute run.

Left idle after one prompt, each AI app let its Mac sleep 96 to 99% of one night

Two nights of 9.5 to 9.7 hours on battery, with each Mac falling asleep on its own under the same battery settings on all three, as pmset -g custom recorded them before each night (display sleep 2 minutes, system sleep 1 minute, Power Nap on) and with the lid open, read from the pmset -g log power log. With one AI app open after a single prompt, the Macs were asleep 96 to 99% of the night. With nothing open, the same Macs the next night: 98 to 99%. One night per condition, each app on a different Mac, and the app was idle: this is not an agent in the middle of a task.

Dark wakes happened both with the app open and with nothing open: the M1 woke 143 times with Claude Desktop open and 121 times with nothing, 108 and 88 of those over Wi-Fi; the M1 Pro on macOS 27, 40 with Claude Code and 101 with nothing; the M1 Pro on macOS 14, 38 and 36. The count moved 2.5 times from one night to the next on one M1 Pro and hardly at all on the other two Macs. One night per condition and one instrument cannot say who asked for each wake; take the shape and not the counts.

That night what the apps held was small, and only on the M1 did the night with the app open sleep less (96% against 98%); the other two Macs slept as much or more with the app open. Claude Code's caffeinate, from the one prompt before the night, lasted 1 minute 4 seconds, as long as the answer ran, and ended before the night's reading began. Claude Desktop's own process held a NoIdleSleepAssertion, a request to macOS not to sleep while idle, named "Electron", for 11 minutes 10 seconds in all and then let go, and the Mac fell asleep 5 seconds later. Each of those was seen once, on one Mac on one night, read by hand from the assertion log. We did not measure an agent in the middle of a long task overnight, the Code tab, or a remote session, which is what several of the GitHub reports describe (anthropics/claude-code issues 64522, 85261, 45769 and 96015). Overnight battery loss we could not measure reliably (the percent gauge is smoothed, and on the first night the morning reading was taken after the charger went in, so the charge counter gives only a lower bound), so the page gives no battery figure for a night.

Closing a coding agent's terminal mid-answer left almost nothing spending on the chip

We let each agent start an answer, then 90 seconds in sent the agent's own process a SIGHUP, the hang-up signal a closing terminal window sends, closed the window and watched the chip for 30 minutes; quitting the terminal app or the agent itself we did not test. Copilot CLI, Codex CLI and Claude Code all read within noise of the control: from 0.006 W below to 0.010 W above, on three Macs on 9 October, and the energy of what was left of each agent's process tree was 0.000 to 0.002 W.

Orphans do exist. The native Copilot CLI binary lived on as an orphan for a day on all three Macs, collecting 36 to 51 seconds of CPU over 21 to 30 hours. Codex keeps a shared background server. On the M1, 2 of ChatGPT's helper processes outlived quitting the app; when we found them they had lived about 6 hours and used 0.1 seconds of CPU in all: they stay, and in CPU time they spent next to nothing; what they do to sleep we did not check.

Open and doing nothing, the apps cost the chip about a tenth of a watt at most

An idle chat window costs the chip about a tenth of a watt at most: 10 minutes with the app open and untouched, on the cable, two days, three Macs. ChatGPT in front: +0.07 to 0.10 W; hidden: 0.00 to 0.01 W. Claude Desktop in front: +0.00 to 0.11 W; hidden: 0.00 to 0.01 W. Cursor in front: +0.03 to 0.05 W; hidden: +0.01 to 0.05 W. On the chip alone, then, an idle chat window is a small cost. For the whole machine we measured still windows only, on battery: ChatGPT in front holding a finished essay cost +1.3 to 1.4 W above the screen by voltage times current on the M1 Pro (1.2 to 1.5 by the charge counter, four runs) and about 0.5 W on the M1, many times what the chip shows, and a TextEdit window set to the same frame holding a ready essay on the same subject cost the M1 Pro about 0.6 W by voltage times current (+0.04 and +0.67 W in its two runs by the charge counter, the weaker reading here; see the window section and the plain-window comparison). An empty window left open we did not measure for the whole machine.

On the chip, a browser tab saved nothing reliable over the app, and for ChatGPT that means Safari

For Claude the tab cost the same as the app or a little more: Safari and Chrome read up to about a tenth of a watt above the Claude app on the chip (the widest gap was 0.13 W), which on the M1, where Claude's app draws under 0.2 W, is 1.3 to 1.7 times the app run next to it in time (1.3 to 1.5 on the day means), and on the M1 Pro with macOS 27 within 15% of it; measured on the M1 on 9 and 12 October and on the M1 Pro on 9 October, with every prompt answered, all on the cable, as means over 8-minute runs of three prompts. For ChatGPT there is no constant winner. Safari cost about 2 times the app on 9 October on both Macs (on the macOS 27 machine in the evening repeat, its morning run being thrown out, below; 1.7 to 2.5 times across the 4 pairs of runs where every prompt got an answer), about 0.9 times on 11 October on the M1 Pro with macOS 27, and about 1.0 times on 12 October on the same machine under the author's account (0.60 against 0.62 W, 6 answers out of 6 on each side). The ratio moved from day to day by more than the difference it was supposed to measure, so we publish the range and nothing sharper. Chrome we cannot average at all: our automated sending into Chrome kept losing prompts, and a lost prompt looks like a cheap one. Of the prompts that did go through, in runs we otherwise threw out, the ones on 12 October on the M1 Pro with macOS 27 drew about what the app's did (0.33 to 0.67 W against 0.52 to 0.86 W, mean chip power in the 140 seconds after sending), on the M1 that night 0.25 and 0.46 W against the app's 0.32 to 0.45 W, and the two on 9 October read higher than the app, 1.2 and 1.0 W.

How we measured

Three used MacBook Pro laptops set aside for measuring and used for nothing else, 16 GB of memory each. Spotlight, automatic system updates and Bluetooth were off; brightness was pinned (0.687 on the two M1 Pro machines, 0.712 on the M1, auto-brightness and True Tone off) and the display never slept during a series. WattMate itself was closed during these runs, except the two window series of 14 October on the M1 Pro, where it was open at 0.9 to 1.5 mW in every run, the controls included, so it sits on both sides of each difference, and the Release check of WattMate on 15 October on the M1 Pro with macOS 27 and the M1, where it was open in every run as well and which is left out of every range (see WattMate next to the lab's instruments). ChatGPT's own updater was left on until the evening of 14 October: that morning it updated the app on the M1 in the middle of a series, and on the M1 Pro with macOS 27 between the morning and evening series; before the evening series it was turned off on those two Macs. ProMotion on the two M1 Pro machines was not set by us, and which refresh-rate setting they were on we did not check.

The ChatGPT repeats of 13 and 14 October also ran on the author's own working MacBook Pro with M3 Max (36 GB). Its brightness was pinned at 0.687 like the M1 Pro machines', but Spotlight, automatic updates, Bluetooth, its appearance and its desktop picture were not checked, and powermetrics was not run there (on the test Macs it runs from a sudoers entry, which we did not add to a working Mac), so it has no chip readings. One extra front run on it had WattMate open; by voltage times current it read 4.69 W above the screen over the whole 30-minute run, 0.1 to 0.3 W more than the runs without it over theirs (4.43 to 4.60), and by the charge counter it sat inside their range. The 4.32 W in the WattMate check below is the same run by the same instrument over the 28 minutes inside WattMate's complete 90-second windows, which leave out the run's first 81 seconds and last 36, when by voltage times current the Mac drew more. One run cannot say whether that difference is the app. It is in the CSV and left out of every range.

Capacity as the battery reports it in the logs of the battery-minutes runs of 11 to 13 October (FullChargeCapacity on macOS 27, AppleRawMaxCapacity on 26 and 14); the hours of the 14 October runs use the capacity in those runs' own logs, up to 4,443 mAh on the M1 Pro with macOS 27; cycles across all the series. The slope of the percent gauge disagrees with it by between 1% less and 9% more, which is why hours and per-hour figures above carry a 10% caveat. Health is the Maximum Capacity macOS reports (System Information, 14 October); the mAh are the battery's own log, a different field, so the two do not divide into each other exactly. The lab ran 5 to 15 October 2026, and the numbers on this page come from all of those days.

Versions and accounts

Accounts: ChatGPT and Codex ran on the test Macs' own account until it hit their usage limits (ChatGPT's daily limit on 12 October, Codex's in the night of 11 to 12 October); the spoiled runs were thrown out (below). From 12 October Codex ran on the author's account on all three Macs, and ChatGPT on the author's account on the M1 Pro with macOS 27 only; the ChatGPT thread on the M1 that day stayed on the test Macs' account and hit the limit. Claude and Cursor ran on the author's accounts throughout. On 13 October ChatGPT ran on the author's account on both Macs that ran it, and on 14 October on the M3 Max; on the two test Macs the 14 October runs did not record the account (the M1 Pro with macOS 27 had been on the author's account on 12 and 13 October). The two ChatGPT accounts were on the same tier. Both agents ran on the author's accounts on 13 October. Opus, thinking modes and voice modes were not measured. Only ChatGPT's version was written down by our runner, at the start of each run from 13 October; the other versions are what was installed, with the gaps shown above. For the Ollama models the digests and quantization were not recorded. The figures are for these versions: an update to any of these apps can change them.

Three instruments, plus one

• The chip. sudo powermetrics -i 5000 --samplers cpu_power,gpu_power: the energy of the CPU and GPU every 5 seconds. powermetrics reports the Neural Engine too; across the 53 series behind this page that have chip readings it came to about 0.0024% of the CPU and GPU energy (the chat models run in the cloud and Ollama runs on the GPU), so the chip figures here are CPU plus GPU. These are the chip's own energy estimates (the cpu_energy and gpu_energy fields of each sample): Apple's manual for powermetrics calls its power figures estimated and possibly inaccurate and warns against comparing them between devices, so read them within one Mac rather than across Macs; differences of a few thousandths of a watt mean nothing. A 5-second reading counts in the interval that contains its midpoint. An integral over each 5 seconds rather than a snapshot: it repeats to tenths of a watt under loads of tens of watts and to hundredths under small ones. It includes the CPU and GPU work WindowServer does for an app. It does not include the display, memory, radios or SSD.
• The charge counter. AppleRawCurrentCapacity in mAh (on macOS 27 inside AppleSmartBatteryPack): the battery gauge's own count of the charge left, 1 mAh resolution, updated about once a minute. Good for runs of 30 minutes and up; in 8-minute runs the sign wobbles. It is an estimate, not a pure sum of current, and around a heavy load it climbs back in steps: in the 30-minute runs of 11 and 12 October by up to 55 mAh in one step on the M1 (during a run of builds) and up to 36 mAh on the M1 Pro machines (just after one); after the 8B model's runs on the M1 on 13 October, by up to 153 mAh. Every battery figure here is the drop between the last readings before a run's two boundaries. Read one tick after each boundary instead, the M1's ChatGPT runs would come out at +13% in front and −19% hidden rather than +51% and +7%; voltage times current gave +45% and +18%, which backs the first reading. Read that way, Claude Desktop's range would be 15 to 57% instead of 19 to 69% and the Codex builds' 130 to 200% instead of 125 to 196%, while ChatGPT in front on the two M1 Pro machines on 11 and 12 October moves by 3 points at most (the first front run of 13 October, by 8). Read the M1's counter figures, every hidden run and the Claude runs as rough; the CSV carries both readings, and the figure at the top uses voltage times current for that reason. The 13 and 14 October data showed one more trait: the counter carries part of one run into the first minutes of the next (see the window section), so for those runs the CSV also carries a reading without each run's first 5 minutes. Watts by this counter are the drop in mAh times the mean voltage of that run, over the run's length; the voltage falls as the battery empties, so two runs with nearly the same drop can differ in watts. Which battery instrument leads was written down before each series' data: the charge counter for the repeats of 13 October, both side by side for the split series of 14 October, voltage times current for the plain-window series; the figure and the percentages at the top use voltage times current for every condition, a choice made after the data of 11 to 13 October.
• Voltage times current. Read from the AppleSmartBattery entry in the IORegistry: on battery, the pack's Voltage times its Amperage; on the cable, SystemPowerIn (under PowerTelemetryData) minus that same product, which is the power going into the battery. The cable figure comes from a different register than the battery one, and while the battery charges it also holds what the charging circuit loses, so a cable figure is set against a cable control. The controller published a new current about once a minute in the 30-minute series, and somewhat more often under the local model's load on 2 of the Macs, a snapshot rather than the minute's average, and a run's figure is the mean of our 10-second readings inside its boundaries, so about 30 snapshots in a 30-minute run. That is a sample, not a sum: it holds for 30-minute runs of a steady or evenly repeating load, and it can land on one phase of a load that repeats close to once a minute (the local model's answers) or spikes for a few seconds (the hidden window coming forward for each prompt).
• Per-process energy. Our own collector read the kernel's energy counter for every process of the logged-in user, and for their coalitions, the groups macOS keeps for an app and the processes it launches, every 10 seconds. Processes running as root, the kernel and WindowServer, which draws the screen, were out of its reach, and WattMate cannot read their energy counters either. WattMate reads the same counter. Activity Monitor's Energy Impact is a score built on the kernel's per-process accounting; which counters it weighs we did not check. Our own tools show up on that counter too: in the ABBA runs of 13 and 14 October our runner's group of processes (the collector, the scripts that send prompts and nettop's single snapshots) was charged 0.009 to 0.011 W in the ChatGPT runs and 0.000 to 0.001 W in the controls. On the test Macs powermetrics runs as root, out of that counter's reach, through the whole series, controls included; the M3 Max ran without it.

How the series were built

• Window states: ABBA order, 8-minute runs, two prompts per run, two repeats per state, on battery. The prompt is always pasted and sent with the window in front; 2 seconds later the window is hidden (⌘H), minimised (⌘M) or covered by a blank TextEdit document stretched over the whole screen, which is one reason "hidden" is not zero. 8 October on three Macs, 10 October on the macOS 27 and macOS 26 machines.
• Battery minutes: one pass per Mac and day in a fixed order: control, ChatGPT in front, ChatGPT hidden, Claude Desktop in front, Codex builds, control. 30-minute runs on battery, 12 prompts per chat run and build tasks back to back in the Codex run; each condition is set against the mean of the two controls. The hidden run always followed the front run, so a gauge tail is possible. 11 October on three Macs; 12 October on the two M1 Pro machines; ChatGPT on the 12th on the macOS 27 machine only, under the author's account.
• ABBA repeats: control, A, B, B, A, control, 30-minute runs on battery, read by rules written down before the runs. 13 October: ChatGPT in front and hidden on the macOS 27 M1 Pro, Claude Code's and Codex's builds on the macOS 14 one; overnight from 13 to 14 October and again in the early morning of 14 October: ChatGPT on the M3 Max.
• Window on screen against the answer, and against a plain window: control, A, B, B, A, control, 30-minute runs on battery, each after a 4-minute warm-up, read by rules written down before the data. 14 October: a still ChatGPT window against answers streaming in it on the macOS 27 M1 Pro and the M1 in the morning, repeated on the M1 in the evening; a still ChatGPT window against a TextEdit window set to the same frame and holding a ready essay on the same subject, on the M1 Pro in the evening.
• Agents on a task: on the cable; two tasks per run; the four-at-once runs start four copies of the agent on four copies of the project. Energy is the chip over the whole run, minus control, divided by the number of tasks.
• Browser tabs: on the cable, chip only, 8-minute runs of three prompts, in ABBA order in the repeats (the first pass on 9 October was one run per tab), with the per-prompt audit described below.
• Terminals: on the cable, 8-minute runs: an empty terminal, Claude Code waiting at the prompt, Claude Code writing three essays.
• Long thread: 12 requests 2.6 minutes apart in one chat, each message scored over the 140 seconds after sending.
• Cursor: three tasks per window state, chip energy from 10 seconds before to 60 seconds after sending; Claude Code's three comparison tasks are counted in one window spanning all three.
• Local model: on battery, one run per model and Mac, answers of about 1,000 tokens with 10-second pauses, plus two 30-minute 8B runs on the M1 on 13 October for the charge counter; the loaded-with-no-requests reading on the cable, voltage times current only, one night.
• Idle apps: on the cable, 10 minutes per window state. Closing: a SIGHUP sent to the agent 90 seconds into an answer, the terminal window closed, then 30 minutes on the chip.
• Nights: one night per condition per Mac; the Mac fell asleep by itself under the same battery settings on all three, as pmset -g custom recorded them before each night (display sleep 2 minutes, system sleep 1 minute, Power Nap on); lid open.
• Before every run a watchdog checked background processes, the lid, the lock screen, brightness and the power source. Prompts were entered through the clipboard and keystrokes, and whether a prompt was actually sent was audited afterwards from the chip's energy in the 140 seconds after sending: 0.25 W or more, rounded to hundredths, means an answer arrived, 0.15 to 0.25 is unsure, below 0.15 is none. A hidden or minimised window draws an answer so cheaply that this audit cannot prove sending there. Claude on the 60 Hz M1 answers below that threshold too: its prompts read a uniform 0.16 to 0.22 W, in the app and in a browser tab alike, and, having seen that, we count those as answers. Unlike the rules of the 13 and 14 October series, these bands were set from runs already made, not written down in advance.
• From 13 October whether ChatGPT answered was read instead from the bytes it and its helper processes received between one prompt and the next, with two single nettop snapshots per prompt, one when it is sent and one before the next: a second instrument, so the check no longer leans on the energy being compared. On the test Macs 20,000 bytes or more is an answer and under 5,000 is none; on the M3 Max, where the app's background traffic alone is about 69,000 bytes in that interval, 110,000 or more is an answer and 80,000 or less is none. The first prompt of each run is not judged (the app's own loading, or bytes lost from connections that closed), and a run counts with at least 10 answers of 11; in the window series of 14 October, with 14 prompts a run, with at least 11 of 13.

What we threw out, and why

• ChatGPT front and hidden runs on 12 October on the two M1 Pro machines on the test Macs' account: its daily limit. On the macOS 27 machine 11 of 12 prompts went unanswered. On the macOS 14 machine the front run was not empty but worse, 0.72 W of chip on every prompt with 0.63 W of it on the GPU and only 0.02 W charged to ChatGPT's processes: most likely a stuck animation on the limit screen rather than answers (not checked by eye). Only the per-prompt audit tells such a run from a real one; its average looks plausible.
• Codex four-at-once on the M1 on 11 October: all four copies stopped at "You've hit your usage limit" after 46 to 72 seconds. Repeated on 12 October under the author's account.
• The ChatGPT thread on the M1 on 12 October from message 8 (the same limit); the macOS 14 machine's thread on 12 October (the cable was pulled mid-run); the last 6 runs of the macOS 27 machine's agents series on 11 October (the lid was closed at about 01:00).
• Every "ChatGPT in Chrome" run, and the Safari runs of 9 October (morning, the macOS 27 machine) and 12 October (night, the M1): the audit showed 0 to 2 of 3 prompts answered.
• Every iTerm2 run of 8 October on the two M1 Pro machines (iTerm2 hung on a permission prompt) and the empty-Ghostty run that iTerm2 spoiled by launching mid-run; the Claude Code runs in Ghostty that day were kept.
• The last 2 hidden-window Cursor tasks on the macOS 14 machine: the file was never touched, most likely a usage limit.
• The first ChatGPT runs of 6 and 7 October: the prompts went into Work mode instead of Chat.
• The first M3 Max series on 13 October: the byte counter itself, nettop in its sampling mode, was charged 4.3 to 4.4 W by the per-process counter in every ChatGPT run (this Mac has no chip readings). It was rerun that night with single snapshots, which cost nothing measurable.
• On the M3 Max, the two hidden runs of the first series (8 and 9 answers of 11) and the second front run of the repeat (8 of 11; one of its prompts read minus 11 MB because a long connection closed and took its bytes with it), by the answer rule; and the extra front run with WattMate open, added outside the ABBA order to check WattMate against the instruments (see WattMate next to the lab's instruments). All are in the CSV and out of the ranges.
• The M1's morning split series of 14 October, after the data: by the answer rule its runs passed, but the window was not drawing the answers (its renderer process near zero, the GPU flat at 0.58 W in every ChatGPT run, ChatGPT updated itself mid-series); see the window section. It was repeated that evening, and every run of the repeat passed.

About the fixes themselves: battery does not care whether an agent solved the task, but a half-done fix is less work, so the ranges above are ranges and not means. We collected every edit of 6 to 12 October and built it off the test Macs. Codex produced 102 edits: 97 fix the bugs, 4 are empty (the limit), and 1 makes the test pass by special-casing its input while leaving the function wrong. Claude Code on Sonnet left one bug in place in 9 of 36 edits across these series, the same 807-byte diff each time.

Most numbers on this page are printed by one script of ours, not published, Scripts/lab/article_numbers.py, from the run folders, and the CSV below is that output in long form, one row per number, with the series it came from. A few come from the lab's notes and are not in the CSV: the edits collected off the test Macs (Codex's 102: 97 fixes, 4 empty, 1 special-cased; Claude Code's 9 of 36 with one bug left, the same 807-byte diff); the agents' own processes at 0.001 W or less (6 October); Codex typing at 0.024 to 0.027 W and the +0.3 to 0.8 W cable reading for a streaming terminal; the two sleep assertions (1 minute 4 seconds, 11 minutes 10 seconds) and the 5 seconds from the second one's release to sleep; the Copilot orphan's 36 to 51 seconds of CPU and 21 to 30 hours of life, and the 0.000 to 0.002 W of the agents' process trees after closing; ChatGPT's helpers' 0.1 seconds of CPU over about 6 hours of life; for Ollama, the 51 and 41 W gauge readings and the roughly 50 W during generation on the cable; the +182% estimate for the 14 October M3 Max front run with a steady control; and for the M3 Max, the one check of the app's background traffic (about 69 KB) and of an answer (about 123 KB), nettop's 4.3 to 4.4 W in the spoiled series and the minus 11 MB prompt; for WattMate's rate of 2, the September test on the M3 Max (about 1.8; we did not keep its raw readings) and its October repeat (1.6 or 2.5); the length of the ready essay in the TextEdit window (1,427 words, a file in our lab scripts); the 2 to 4.5 mW of a Release build of WattMate measured on its own; and what WattMate's menu said on the M1 on 15 October (the apps under half a watt, Screen and system at 4.5 W, "Nothing to quit"), read by our script through macOS Accessibility, without a screenshot.

What we did not measure

• Any Mac other than these four: no M2, M4 or M5, no Intel, no MacBook Air; and on the M3 Max only the ChatGPT window, with no chip readings.
• Temperature. Nothing here says what got warm; the page says "draws power" because that is what was measured.
• The energy spent in the data centre on your behalf.
• Opus, thinking modes, voice modes, Computer Use, and a task running remotely while the laptop only watches.
• Long idle and indexing in Cursor, VS Code with Copilot, or Zed; an agent waiting on a permissions question; eight agents at once; MCP servers.
• Codex's Computer History waking the display; an agent in the middle of a task overnight.
• ChatGPT's Work mode; ChatGPT in Chrome; Copilot CLI writing an answer; LM Studio and MLX.
• The static window against the answer, and against a plain window, on the M3 Max and the M1 Pro with macOS 14; a plain window on the M1; any window series in light appearance or with a window of another size; the desktop picture behind the windows, which no run recorded, and the appearance, recorded only by a check on the morning of 14 October (on a mini-LED screen what the desktop shows can change what the screen draws); a blank ChatGPT window; four agents at once on battery.
• The whole machine on battery for a long thread, a terminal streaming text (on the cable one series gave a direction only), a browser tab, an empty window left open (a still window with a finished essay was measured, in the window section), ChatGPT minimised or covered, and Claude Desktop hidden, minimised or covered.
• The length of each answer, how long it streamed, and which model answered in ChatGPT's Chat mode; the bytes logged from 13 October tell whether an answer came, not how long it was.
• A repeat by anyone outside WattMate: every series here was run and read by us.

What WattMate will and will not show you

This section is about our own app, not the study: no figure above was read from WattMate. This page was measured with powermetrics, the battery's own counters and a per-process collector, not with the app, and WattMate was closed in every run except in three places: one extra M3 Max run, left out of every range; the two window series of 14 October on the M1 Pro, which are counted and where WattMate cost 0.9 to 1.5 mW; and the Release check of 15 October at the end of this section, also left out of every range. The check below uses the M3 Max run, a separate session on the M1 and that Release check. At the top it shows what the whole Mac draws, read from the battery's current and voltage, the instrument behind the "voltage times current" column above. Each app's row is an estimate: it starts from the per-process kernel counter that produced the "ChatGPT processes" column and is scaled up to battery watts, because each joule that counter charges to an app's processor work costs the battery more than a joule (power conversion, memory and the rest of the path), plus the graphics that can be tied to that app. What no app is charged for goes into a block of its own, "Screen and system", so the rows and that block add up to the figure at the top: the block is what is left. It holds the screen, memory and radios, what no per-app counter sees, such as most of what a window in front costs, and whatever the app rows miss or overcount, since each row is an estimate at one rate; the check below shows how large that can be. How the count works is on how we count. Since version 1.5 WattMate also has a row for each coding agent, with the builds it launched counted under it as far as WattMate sees them before they exit: in the M1 session below, the Terminal's row still carried nearly half the build work.

WattMate next to the lab's instruments

The table below compares WattMate's own records with the lab's instruments twice, on battery: in the extra M3 Max run, ChatGPT answering in front for 30 minutes, and in a session on the M1, macOS 26, where Claude Code ran builds for 100 minutes (a debug build of 1.5 in development, before the fix described further down this section, not one of the series above). We set what WattMate wrote to its own database, in 90-second windows, against the lab's readings for the same minutes. A third check, on 15 October, used a Release build and also ran the window hidden; it closes this section.

The first five rows check bookkeeping. WattMate reads the same battery register and the same kernel counter as our collector, so agreement there shows that it adds up time and energy correctly, not that the sensors are right. The charge counter is the one other whole-Mac reading: it comes from the same battery controller as the current but is kept by the battery's own gauge, and on these runs it disagreed with the current reading by 2 to 3%.

Doubling is WattMate's one rate, the same on every Mac, for what a joule of an app's processor work costs the battery, and it is a rounded compromise rather than a constant the battery obeys. It was chosen in September from the app's own records on the author's M3 Max and checked there by switching a processor load on and off, which gave about 1.8 battery joules per counted joule (we did not keep those raw readings, and a repeat in October gave 1.6 or 2.5 depending on what we took as the background). On the three lab Macs the same test gave 1.44 to 1.61, below 2. For builds launched by coding agents we have one check, on the M1, and it sets only a ceiling on that rate: the doubled counters came to about 95% of the Mac's whole rise above the screen (the table above), a rise that also holds what no counter sees.

The rows after that show the limit. With ChatGPT answering in front, the M3 Max drew 4.32 W above the screen alone by voltage times current over those 28 minutes, 4.28 W by WattMate's record of the whole Mac less the same screen-alone control. The kernel counter saw 0.26 W in all user processes, and WattMate, which doubles that counter and adds the graphics tied to an app, listed the apps at 0.54 W, ChatGPT at 0.51 W. The other 3.75 W went to Screen and system, on top of the 2.85 W the whole Mac draws with the screen alone (the series' control runs, not the display by itself). Most of that part goes away when the window is hidden: hidden, the same answers cost this Mac about a watt or less (see the window section). Up to version 1.4, WattMate's description of that block said quitting an app removes none of it, which is wrong for a window in front. The method text of version 1.5 says that quitting an app can take part of the block with it; one line in the menu still says the rest cannot be quit, until version 1.6.

On the M1, during builds, the doubled counters came to 1.49 W against the Mac's 1.57 W rise above the screen by voltage times current, and the rest of that rise includes the Terminal window with its scrolling text. WattMate still showed the apps at only 0.82 W: it scales the rows down when together they would leave the Mac less than a fixed allowance for simply being awake, set on the author's M3 Max, and on this M1 that allowance sat above what the Mac really draws idle. It took off about 45%, and that build work went to Screen and system as well.

In builds before that fix, the two measured here among them, WattMate's average watts for a 90-second window read 5 to 6% high while its energy did not: the window's length was capped at 90 seconds and its energy was not. Version 1.5 divides by the true length. The 1.5 and 1.2 mW in the table are a debug build read by our collector in those two sessions; the home page's 2 to 4.5 mW is a Release build measured on its own, idle and while an agent worked. Both are thousandths of a watt. These two sessions used debug builds, and what WattMate's menu showed was not captured in them. Every number in the table is in the CSV, section "WattMate against the lab instruments".

The third check, on 15 October, asked whether WattMate's row for an app shows what hiding its window saves. We ran a Release build of the code going into version 1.5, as it stood on the morning of that day, on two of the lab Macs, the M1 Pro with macOS 27 and the M1, with WattMate open in every run, controls included: 30-minute runs on battery in the order screen alone, ChatGPT answering in front, hidden, hidden, in front, screen alone. All eight ChatGPT runs passed the answer rule and the renderer rule, and how to read the result was written down before the data. WattMate's whole Mac stayed within 2% of voltage times current in every run. Hiding the window cut the whole Mac's draw by 2.39 W on the M1 Pro and 0.80 W on the M1 by voltage times current; WattMate's ChatGPT row fell by 0.53 W and 0.18 W, 22 and 23% of that saving (19 and 15% of the saving by the charge counter; on the M1 Pro that reading rests on the second front run alone, because the counter's two readings of the first disagreed by more than 10 points). In WattMate's own records, over its 90-second windows inside those runs, the whole Mac fell by 2.30 and 0.99 W, and almost all of that beyond the row went to Screen and system (1.77 and 0.82 W); measured against voltage times current over those same windows, the row's share comes to 24 and 19%, so how it is counted moves the share between 15 and 24% and not further. On the M1, the one Mac where our script could read the menu during the series, it showed the apps under half a watt, Screen and system at 4.5 W and the line "Nothing to quit" after a run with the window in front. So for a window in front, WattMate's row shows about a fifth of what hiding it saves, and the menu does not point at the window; the saving shows in the whole Mac's total. The run numbers are in the same CSV section; what the menu said is not, it comes from the lab's notes.

Earlier measurements on this site

These came from a working machine's log rather than from a lab, one or two Macs each, and they are the reason the lab exists:

• Claude on a Mac: the desktop app and Claude Code are two programs with opposite habits, from one Apple silicon MacBook's log.
• Chrome: the same browser worth 6 times more battery on one Mac than on another.
• Slack: a near-zero median both times it was measured, and a spike that did not return.
• Spotify: the spikes are real and brief.
• Telegram: measured twice, and set against Slack.
• Xcode: builds that briefly become the whole machine, which is the shape the agents above inherit.

Results data

ai-battery-usage-mac.csv, 2,478 rows, one row per number as printed: the results, not the raw instrument logs. Columns: section (the series), instrument, power (cable or battery), series (the lab series the number came from: its start time in UTC and name), stand (the Mac, by chip and macOS version), day, run (the timed interval under one condition), metric, value as printed, and note. Runs we threw out are in the file too, with the reason in the note column, so you can see what was dropped and not only what was kept; the exceptions are the first M3 Max series (spoiled by the byte counter), the Work-mode runs of 6 and 7 October, the macOS 14 machine's long thread of 12 October (the cable was pulled) and the last 6 runs of the macOS 27 machine's agents series of 11 October (the lid was closed).

The measurements behind this file and the code that turns them into it are archived at Zenodo, doi.org/10.5281/zenodo.23391845 (data under CC BY 4.0, code under the MIT licence): one folder per series and per night, scripts that recompute 2,396 of the 2,478 rows from those folders and check each one against this file, and the reason for each of the other 82. Those 82 compare WattMate with the lab's instruments and need WattMate's own database, the collector's full per-process log or a series that is not in the archive; neither the database nor the raw collector logs are published, because both record every app and process on the Mac.