Mac Sleep Can Burn Your Claude Code Usage Limit. Here Is Why

Q: Does caffeinate stop the cache rewrites?

With the lid open, yes for idle sleep: caffeinate -i -w "$(pgrep -nx claude)" keeps the Mac awake until that Claude Code process exits, so agents never pause long enough for the cache to expire. It does not stop the sleep that closing the lid causes.

It can. When a Mac sleeps mid-run, Claude Code's background agents stop mid-request and their prompt cache can expire. On each wake they re-send the whole conversation, which is written to the cache again, and GitHub reporters describe weekly limits dropping by a quarter or more overnight with almost no output. The fix is to keep the run either fully awake or fully stopped: caffeinate -i or Claude's Keep computer awake with the lid open, Clamshell for Mac with it closed, or stop the agents before you close the lid.

5 minutesSubagent and workflow cache, by default

1 hourMain conversation, subscription

26 wakesIn one 6.5-hour report, lid closed

$9.99 onceAfter a 7-day free trial

Clamshell for Mac keeps the Mac fully awake with the lid closed while armed, so agents finish their work instead of pausing and re-sending it. Free for 7 days.

Download free trial

Apple Silicon, macOS 14+. Notarized by Apple. 3.6 MB. Or buy now, $9.99

Asleep, then awake for seconds.Each short wake is long enough to re-send an agent's whole context, and too short to get the answer back. The cache has expired, so the context is written again every time.

In mid-October 2026, several people opened GitHub issues against Claude Code with the same story: they closed the lid, or let the Mac idle-sleep, while background agents or a workflow were still running, and found a large part of their weekly limit gone in the morning with very little to show for it. This page separates what Anthropic documents from what those users report, then shows how to check your own Mac and how to stop paying for wake-ups.

What Anthropic's docs say about the cache

Claude Code reuses a prompt cache so it does not reprocess the whole conversation on every request. Entries expire after a period of inactivity, the TTL (time to live). Anthropic's prompt caching docs set the default per request:

Request	Claude subscription, within plan usage	Usage credits, API key or cloud provider
Main conversation	One hour	Five minutes
Subagents, workflow agents, everything else	Five minutes (a few server-controlled helper requests get one hour)	Five minutes

Agents get the short cache. The docs say subagents fall outside the main-conversation bucket and "get five minutes even on a subscription", and the workflows docs say the same for workflow agents.
Over the plan limit, the main conversation drops too. Once you draw on usage credits, Claude Code switches the main conversation to the five-minute TTL.
You can choose. promptCacheTtl sets the main conversation and subagentPromptCacheTtl everything else, to 5m or 1h; the environment variables CLAUDE_CODE_PROMPT_CACHE_TTL and CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL do the same. Both need Claude Code 2.1.242 or later.
Writes cost more than reads. On the Claude API price list, a five-minute cache write costs 1.25 times base input and a one-hour write 2 times, while a cache hit on Opus 5.5 or Sonnet 5.5 costs 0.05 times. Rewriting a context therefore costs 25 times what reading it would. Anthropic does not publish how cache writes weigh against a subscription's limits.

Two more documented facts matter here. The agent view docs say background sessions "are also preserved when your machine sleeps. Their processes resume on wake", so sleep does not lose your work. And the errors reference says that when Claude Code detects the computer went to sleep while a response was streaming (Your computer went to sleep mid-response), it treats the connection as broken once the Mac wakes. That partial response has to be requested again.

The gap decides the price. A request inside the cache lifetime reads the cached context cheaply. A gap longer than five minutes, which every sleep is, means the agent's next request writes the whole context again.

What the Claude Code changelog says

Anthropic has fixed several sleep problems this month. From the Claude Code changelog, with dates from the GitHub releases:

2.1.287, October 1: "macOS: Fixed Remote Control sessions started with claude remote-control stopping mid-turn when the Mac went to idle sleep".
2.1.290, October 5: "Fixed background agents failing with "Agent stalled" and Workflow tool subagents restarting from their prompt when a Mac woke from sleep", and "Fixed automatic compaction giving up with "Prompt is too long" when a Mac went to sleep while it was running".
2.1.300, October 14: added cache_creation_5m_tokens and cache_creation_1h_tokens to the OpenTelemetry api_request event, so you can see which lifetime your cache writes used.

None of the entries from 2.1.287 to the current 2.1.302 changes the default cache TTL, and none addresses re-sending requests during brief wakes.

What users report

These are user reports, open as of October 17, 2026. Nobody from Anthropic had confirmed the billing impact in the threads, and the first three cross-reference each other, so treat them as one cluster with several reporters rather than independent proof.

Report	Setup	What the reporter measured
#102597, Oct 15	Lid closed on battery, two background subagents mid-stream	26 sleep and wake cycles about every 15 minutes over 6.5 hours, 81 requests sent and 29 completed, 15 full cache rewrites of about 7.1M tokens, about 7K output tokens, weekly usage from 20% to 56%
#102269, Oct 15	Desktop app Code tab, a 7-agent workflow left running overnight	Weekly limit down about 25%; a follow-up comment lists 75 cache writes after pauses longer than five minutes, 30.3M cache write tokens, all on the five-minute TTL
#102780, Oct 16	Three background agents, Mac idle-sleeping about every 15 minutes	About six hours of "went to sleep mid-response" cut-offs, each retry re-sending about 80K tokens with zero cache reads
#102276, Oct 15	Claude Code 2.1.300	Main-conversation cache writes switched from one hour to five minutes

About the 2.1.300 TTL claim. Issue #102276 is labelled a duplicate, and a commenter's correction in the thread says the five-minute writes were not tied to the version: interactive sessions started on October 15 got five-minute writes on both 2.1.299 and 2.1.300, while claude -p kept one-hour writes, and setting "promptCacheTtl": "1h" switched a running session back. The changelog lists no TTL change, and the docs still give subscriptions a one-hour main-conversation cache. On the Mac this page was written on, every main-conversation cache write that 2.1.300, 2.1.301 and 2.1.302 recorded from October 15 to 17 was a one-hour write. That is one account, so check your own (below) rather than assume either way. Agents and workflows get five minutes by default regardless.

Why the half-asleep state is the expensive one

Fully awakeAgents keep working and read their cache between requests.

Asleep with brief wakesRequests go out on each wake, the Mac sleeps again before they finish, and the cache has expired.

Fully asleepNothing is sent. The work waits for you and resumes on wake.

The reporters' logs show the middle case. A sleeping Mac still wakes briefly on its own (the #102597 log shows a DarkWake about every 15 minutes), and in that report Claude Code noticed the frozen stream on each wake and re-sent the request straight away. The retry paid a full cache write and was frozen again seconds later. In #102780 the Mac was idle-sleeping with the lid open, so the same loop can happen at your desk.

Closing the lid does not keep the Mac awake for a busy agent. Apple's developer note QA1340 classes closing the lid as forced sleep, which apps can delay but not prevent.

Check your own Mac

Did the Mac sleep during the run? The pmset manual says -g log shows the history of sleeps and wakes:
```
pmset -g log | grep -E "Entering Sleep|DarkWake|Wake from"
```
A row of short wakes roughly every 15 minutes through the night is the pattern in the reports.
Which TTL do your writes use? Anthropic's docs give this test. Look at usage.cache_creation: one-hour writes appear under ephemeral_1h_input_tokens, five-minute writes under ephemeral_5m_input_tokens.
```
claude -p "hello" --output-format json
```
It runs in print mode, which the #102276 thread says was not affected, so an interactive session can differ.
How often did the cache miss? In a session, run /usage. From 2.1.251 the Session block has a Prompt cache (main) line with the hit ratio, the misses and whether the cache is warm right now.
Is something holding the Mac awake now? pmset -g assertions lists every sleep hold, including caffeinate and Clamshell's.

Fixes, cheapest first

Stop or pause agents before you close the lid

Free, and the right call if the run can wait. A fully asleep Mac sends nothing, and agent view preserves the sessions so they resume when you come back. The reporter of #102597 suggests the same thing: fully awake or fully asleep, not in between.

Lid open: caffeinate or Keep computer awake

Free and enough at a desk. caffeinate -i -w "$(pgrep -nx claude)" blocks idle sleep until that Claude Code process exits. In the Claude desktop app, Keep computer awake in Settings, This computer, System prevents idle sleep. Both stop at a closed lid; Anthropic's docs add that closing the lid still puts the Mac to sleep.

Set the cache to one hour

Add "subagentPromptCacheTtl": "1h" (and "promptCacheTtl": "1h" if your writes show five minutes) to ~/.claude/settings.json. Gaps under an hour then read the cache instead of rewriting it. It does not stop the re-sending, longer gaps still rewrite, and one-hour writes are priced at twice base input.

Lid closed: Clamshell for Mac

Keeps an Apple Silicon MacBook on macOS 14 or later fully awake with the lid closed while armed, on power or battery, with no external display, sudo or admin rights. No brief wakes, so no re-sent context. The agents keep working and keep using your limit on real work. If macOS reports serious thermal pressure, Clamshell disarms toward normal sleep. $9.99 once after a 7-day trial.

Try it free

Two more ways exist. Apple's clamshell mode keeps a closed MacBook awake with power, an external display, keyboard and mouse attached. sudo pmset -a disablesleep 1 stops lid sleep with nothing attached, but it is a global admin switch that stays on until you undo it; read pmset disablesleep explained first.

Arm only around a run

Clamshell has a URL scheme and Shortcuts actions (Arm, Disarm, Toggle and Status). A wrapper arms it for one job and disarms when the job ends:

open "clamshell://arm"
claude -p "run the test suite and fix the failures"
open "clamshell://disarm"

The arm request is asynchronous, so check the menu bar state before you close the lid. Clamshell does not detect Claude Code or its agents, so it does not disarm on its own when they finish; the last line, a Shortcut, or Claude Code hooks do that. The hooks recipe arms on session start and disarms when the last session ends.

Clamshell keeps your Mac awake with the lid closed. Free for 7 days, then $9.99 once for one Mac. 14-day money-back guarantee.

Download free trial

Frequently asked questions

Does Claude Code use my usage limit while my Mac is asleep?

Not while the Mac is fully asleep, because nothing is sent. The cost comes from the brief wakes in between: GitHub reporters describe background agents re-sending their whole conversation on each wake, writing it to the prompt cache again, and the Mac sleeping again before the answer arrives. Anthropic had not confirmed the billing impact in those threads as of October 17, 2026.

How long does Claude Code's prompt cache last?

Anthropic's docs say the main conversation gets a one-hour cache on a Claude subscription within plan usage, and five minutes on usage credits, an API key or a cloud provider. Subagents and workflow agents get five minutes by default, even on a subscription, unless you set subagentPromptCacheTtl to 1h.

Did Claude Code 2.1.300 change the prompt cache TTL from one hour to five minutes?

Not according to the changelog, which lists no TTL change from 2.1.287 to 2.1.302, and the docs still give subscriptions a one-hour main-conversation cache. Issue #102276 reported five-minute writes on 2.1.300; a commenter's later correction tied them to interactive sessions started on October 15 rather than to the version. Check your own writes with claude -p "hello" --output-format json.

Does caffeinate stop the cache rewrites?

With the lid open, yes for idle sleep: caffeinate -i -w "$(pgrep -nx claude)" keeps the Mac awake until that Claude Code process exits, so agents never pause long enough for the cache to expire. It does not stop the sleep that closing the lid causes.

Will keeping the Mac awake with the lid closed save usage?

It removes the sleep and wake cycles that make agents re-send their context, but the agents keep working, so they keep using your limit on real work. If you do not need the run, stopping the agents before you close the lid is the cheapest option.

Related guides

Sources checked October 17, 2026: Anthropic's Claude Code docs on prompt caching, workflows, agent view, errors and desktop scheduled tasks; the Claude API prompt caching price list; the Claude Code changelog and GitHub release dates; GitHub issues #102597, #102269, #102780 and #102276 (user reports); Apple Technical Q&A QA1340; and the macOS caffeinate and pmset manual pages. Clamshell behavior is described from its published facts. Clamshell is an independent app, not affiliated with or endorsed by Anthropic or Apple. Claude and Claude Code are trademarks of Anthropic.