"usage limit reached." Mid-flow, at the worst possible moment. What if that line never landed when you need it most?
The thread running through this article fits in one sentence: your 5-hour window starts at your first prompt, so you decide when your Claude day begins. All that's left is to make that choice while you sleep.
If you use Claude (and especially Claude Code) heavily, you know the moment: mid-refactor, mid-feature... "usage limit reached." Blocked. Come back in a few hours.
Why? Claude runs on a rolling 5-hour window. And the detail that changes everything: that window doesn't start at midnight, or at any fixed time. It starts the exact moment you send your first prompt.
So the root cause of the waste isn't your quota, it's when you open the first window, left to the chance of when you happen to sit down at your desk. And that's where it gets interesting: that moment is yours to choose.
Do the count. If your first session starts at 5 AM, here's your day:
| Session | Window |
|---|---|
| 1 | 05:00 → 10:00 |
| 2 | 10:00 → 15:00 |
| 3 | 15:00 → 20:00 |
| 4 | 20:00 → 01:00 |
Four full sessions that line up perfectly with a workday (and an evening of side projects 😏).
Compare that with someone who fires their first prompt at 9:30 when they get to the office: their second window doesn't open until 2:30 PM, the third at 7:30 PM... They only really use two or three. By simply shifting the starting point, you reclaim a whole window per day: no plan change, no extra cost.
The catch, obviously: nobody wants to get up at 5 AM to say hello to an AI.
Most people's first instinct: open an interactive session and type a quick "hello"
or "hey Claude"
to kick off the window.
It works, but it's wasteful. An interactive session loads a whole context (system prompt, CLAUDE.md, repo state...), and Claude generates a warm reply nobody will read. Tokens burned for nothing.
Second instinct, smarter on the surface: "what if I just use /usage? That costs nothing!"
That's exactly the trap: ** /usage probably doesn't start the window.** It's a read-only lookup command: it shows your consumption and the next reset time, but it sends no prompt to the model. And the 5-hour window starts at your first
/usage
.The principle is simple: you need a real request to the model, but the smallest one possible. A one-word prompt, no useless context, ideally on the cheapest model (Haiku). Cost: a handful of tokens, negligible, including against your weekly quota. But the 5-hour window opens.
The next section shows how to send this micro-prompt automatically, machine on or off.
And what about /usage
? Keep it for its real job: verifying. Open Claude Code after the automatic wake-up, type /usage
, and you'll see your "Current session" bar active with the reset time. That's your proof the wake-up worked.
💡 Want to check for yourself that /usage isn't enough? Wait for your window to expire, run only /usage, then look at claude.ai/settings/usage: no session timer starts.
The whole point of the strategy is that it runs in the background. You sleep. Two methods, from simplest to most hands-on.
/schedule
, Claude Code's native routines This is the cleanest method, and it makes almost everything else obsolete. Claude Code has built-in routines: automations you configure once, then run on Claude Code's cloud infrastructure. Translation: your machine can be off, the routine runs anyway. No cron, no Raspberry Pi, no VPS.
In a Claude Code session, just type:
/schedule a daily routine at 5:00 AM that just replies "ok" and does nothing else
(You can also create and manage your routines from claude.ai/code.)
Why it's perfect for our case:
⚠️ The winter-time trap: routines are scheduled in UTC cron, not your timezone. If you're in Paris, "5 AM" translates to 0 3 * * *
in summer (CEST = UTC+2)... but that same cron will fire at 4 AM the moment daylight saving ends (CET = UTC+1). The shift is silent: nothing breaks, your window just opens an hour too early and your last session ends at midnight instead of 1 AM. Two options: accept the drift, or move the cron to 0 4 * * *
in late October (and back in late March). Conversely, local cron (Method 2), launchd, and Task Scheduler follow your machine's local time and therefore don't have this problem: it's specific to UTC-based schedulers (routines, GitHub Actions cron).
💡 Side note: the scheduler adds a few minutes of random jitter. Your "5 AM" routine will land closer to 5:05–5:10. Irrelevant for the strategy.
One command, once, and it's set for every morning.
If /schedule
isn't available in your environment (Claude Code web disabled, company policy...), you can schedule a minimal prompt in headless mode from your own machine.
⚠️ Important warning: Anthropic recently changed how non-interactive usage is billed. Since mid-June 2026, claude -p
, Agent SDK, and GitHub Actions calls are reportedly counted against a separate monthly credit from your subscription (no longer the shared session pool). Possible consequence: a claude -p
in cron might no longer open the 5-hour window for your interactive sessions. Test at home before relying on it (see the /usage
check above). And if it stops working, Method 1 remains the safe bet.
crontab -e
0 5 * * * /usr/local/bin/claude --model haiku -p "ok" >> ~/claude-wakeup.log 2>&1
💡 Check your binary's path with which claude
. The log lets you confirm at wake-up that everything ran fine.
The advantage of launchd
: if the Mac was asleep at 5 AM, the job runs when it wakes. Create ~/Library/LaunchAgents/com.claude.wakeup.plist
:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.claude.wakeup</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/claude</string>
<string>--model</string>
<string>haiku</string>
<string>-p</string>
<string>ok</string>
</array>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>5</integer>
<key>Minute</key>
<integer>0</integer>
</dict>
</dict>
</plist>
launchctl load ~/Library/LaunchAgents/com.claude.wakeup.plist
schtasks /create /tn "ClaudeWakeUp" /tr "claude --model haiku -p ok" /sc daily /st 05:00
With Method 1, the question is moot: routines run in the cloud. If you're set on home-grown cron, schedule the machine's wake in BIOS/UEFI (or pmset repeat wakeorpoweron
on Mac), or offload the job to an always-on machine: a Raspberry Pi, a small VPS (claude setup-token
to generate an OAuth token), or a scheduled GitHub Action (careful: GitHub's cron is UTC).
Two things to keep in mind:
One /schedule
command, zero dawn alarm, and your Claude day begins while you sleep:
/usage
: an /usage
serves to confirm the wake-up worked/schedule
(cloud routines, from the Pro plan) = it all happens So the real question isn't "how do I get more quota?". It's:
"What time do I actually want my Claude day to begin?"
Answer that, schedule it once, and let the machine handle it. Claude, wake up. Me, I'm still asleep. 😴
I write about the small automations that take friction out of a developer's day. Let's talk on LinkedIn.