How long can Claude Code run?

There is no hard wall-clock limit: a Claude Code session can run for hours on a single job. What actually stops a long run is your usage clocks, not a timer. Separate those two things and long unattended runs become a design problem rather than a guessing game.

Runtime is not the limit; the usage windows are

Claude Code will not stop because a stopwatch hit a number. It keeps working as long as it has work to do and capacity to do it with. The documentation is explicit about this: the --max-turns flag exists precisely because there is no limit by default, and without one the agent loop runs until Claude decides it is finished. The capacity is metered on two clocks that run at the same time:

• A rolling five-hour session window, anchored to your first message and rolling off continuously.
• Weekly caps, which are really two ceilings: one across all models and one for Opus only.

Both refill automatically. Neither is a daily limit; there is no daily limit on Claude subscriptions.

One change is worth knowing if your reference points are old. On May 6, 2026 Anthropic removed the peak-hours limit reduction on Claude Code for Pro and Max accounts, and doubled Claude Code's five-hour rate limits for Pro, Max, Team, and seat-based Enterprise plans. Long runs got materially more room that day, and as of August 2026 there is no active peak-hours penalty for subscription users. See Claude peak hours.

What actually ends a long run

In practice, four things stop unattended runs, and only one of them is about capacity:

• The usage window. The most common ceiling on a genuinely long job, and also the most predictable: check /usage before you start.
• An ambiguous instruction. The agent reaches a fork it cannot resolve and waits for a human. This is the biggest silent killer of overnight runs, and it is entirely a prompt problem.
• A failing command it retries. A flaky test, a missing credential, or a network call that times out can burn a lot of capacity going nowhere.
• The per-turn tool-use cap. A single turn that fans out into too many calls stops early; see what "Claude reached its tool-use limit for this turn" means.

Three of the four are fixed by writing a better job, not by buying more plan.

Structure work that survives an interruption

Assume the run will be cut somewhere you did not choose, and make that cheap:

• Commit early and often. A run that commits after each unit of work leaves you a usable branch even if it stops halfway. A run that commits once at the end leaves you nothing.
• Write state to a file the next run can read. A simple progress log of what is done and what is next means resuming costs one prompt instead of a fresh exploration.
• Keep a plan document. Have the agent write the plan first, then work through it and check items off. The plan doubles as the resume point.
• Scope one job per run. Two loosely related goals in one run is how agents drift. One job, one finish line.
• Prefer verifiable end states. "The test suite passes" or "the report is written to this path" beats "improve the codebase". A verifiable end state lets the agent know it is done, and lets you know whether it succeeded without reading everything.

Overnight and scheduled runs

Long work belongs at hours you were not using anyway. An eight-hour night comfortably fits a job that would eat a working session, and it is not competing with your daytime windows. The best Claude Code overnight tasks covers jobs that run unattended safely, and set-and-forget Claude Code agents covers the three properties that make a job safe to walk away from: narrow scope, a clear stopping condition, and output that cannot break anything before you look.

Better still, do not rely on remembering to start it. Scheduling Claude Code runs recurring jobs on Anthropic cloud at a cadence you choose, with your machine off and Claude Code closed. That turns "how long can I leave it running?" into a question you answer once. For a broader menu of what to point it at, see productive uses for idle Claude Code.

How much capacity is a long run even using?

Here is the thing people miss when they worry about run length: weekly capacity is a ceiling, not a balance. Whatever you have not used when your window resets does not carry forward. It is gone.

So the cost of a long overnight run is usually not "capacity I needed for something else". It is capacity that was going to expire. Check Settings > Usage or run /usage; if your weekly bar routinely finishes well short of full, the real constraint on long runs is not your plan, it is having a job worth running. See how to check your Claude usage.

A well-scoped unattended run, as an example

Tokens for Good is a good model of the shape described above, which is why it works well as a long or scheduled run. Your Claude Code claims a queued nonprofit, researches its real-world impact against a fixed methodology with citations, submits a structured report, and stops. It has a clear end state, so it does not drift. It is safe to leave alone, because it writes a report rather than touching anything of yours. And it uses capacity that would otherwise reset unused, running on the subscription you already pay for with no separate API cost.

Quality is handled after the run, not during it: every organization is researched twice by independent contributors, then validated, consolidated, scored deterministically, and human-reviewed before it reaches the public directory. "Tokens" here means AI model tokens, not crypto: no coin, no wallet, no blockchain. See how the research works, or the docs to set it up in about a minute.

Frequently asked questions