Claude Code 5-Stunden-Limit: Änderungen prüfen, Checkpoint sichern und fortsetzen

Wenn Claude Code mitten in einer Aufgabe das Fünf-Stunden-Limit erreicht, beweist die letzte Antwort nicht, dass die Arbeit fertig ist. Der neue Graceful Stop ist ein Best-Effort-Puffer: Das Tool kann eine kleine feste Zuteilung aus dem wöchentlichen Usage verwenden, um einen sichereren Haltepunkt zu suchen. Es verspricht aber weder einen sauberen Working Tree noch einen Commit, erfolgreiche Tests oder eine abgeschlossene Funktion.

Gehen Sie in dieser Reihenfolge vor:

1. Lesen Sie Limit-Typ und Reset-Zeit genau.
2. Prüfen Sie staged, unstaged und untracked Änderungen.
3. Führen Sie die kleinste aussagekräftige Validierung aus.
4. Erstellen Sie einen wiederherstellbaren Git-Checkpoint.
5. Entscheiden Sie erst dann zwischen Warten, Usage Credits und einer API.

So wird aus einer unsicheren Unterbrechung eine kontrollierte Übergabe. Außerdem zahlen Sie nicht für weitere Nutzung, bevor Sie den Zustand des Repositories kennen.

Graceful Stop ist ein Puffer, keine abgeschlossene Aufgabe

Die Ankündigung von Claude Developers besagt, dass Claude Code bei einem Limit mitten in der Aufgabe versuchen soll, einen geeigneten Haltepunkt zu finden. Dafür steht eine kleine feste Zuteilung aus dem wöchentlichen Usage zur Verfügung. Entscheidend ist versuchen, nicht „garantiert abschließen“.

Ein Nutzer berichtete von einem saubereren Stopp als bei früheren Abbrüchen mitten in einer Änderung. Das ist ein hilfreicher Einzelbericht, aber keine allgemeine Zuverlässigkeitsgarantie.

Trennen Sie drei Mechanismen:

Mechanismus	Was er schützt	Was er nicht garantiert
Graceful Stop am Limit	Gibt dem Agenten etwas Raum für einen kohärenteren Abschluss	Fertigstellung, Commit, sauberer Tree, erfolgreiche Tests
Claude-Code-Checkpoint	Mit /rewind lassen sich viele direkte Dateiänderungen der Sitzung zurücksetzen	Bash-Änderungen, die meisten Subagent-Edits, externe Änderungen, vollständige Repo-Historie
Git-Checkpoint	Hält einen prüfbaren, verzweigbaren und wiederherstellbaren Zustand fest	Korrektheit ohne Review und Tests

Der Graceful Stop kann eine bessere Zusammenfassung oder weniger halbfertigen Code hinterlassen. Die tatsächliche Abnahme beginnt trotzdem bei Git.

Ermitteln Sie zuerst, welches Limit Sie gestoppt hat

Nicht jede Sperre verschwindet nach fünf Stunden. Die Anthropic-Dokumentation zu Usage Limits unterscheidet Nutzungs- und Kontextlängenlimits; der Verbrauch kann zudem zwischen Claude-Oberflächen desselben Kontos geteilt werden.

Lesen Sie die Meldung wörtlich:

• Approaching 5-hour limit: Es bleibt ein kurzes Zeitfenster, um den Scope nicht weiter zu vergrößern und den Checkpoint vorzubereiten.
• 5-hour limit reached — resets …: Maßgeblich ist die angezeigte Reset-Zeit.
• Ein wöchentliches oder modellspezifisches Limit kann nach dem Fünf-Stunden-Reset bestehen bleiben.
• Kapazitäts- oder Servicefehler sind kein aufgebrauchtes Kontingent; zusätzliche Zahlung behebt keinen Ausfall.

Wenn der aktuelle interaktive Client anbietet, die Sitzung offen zu halten, auf den Reset zu warten und automatisch fortzufahren, kann das der einfachste Weg sein. Prüfen Sie jedoch den Hinweis Ihrer Version und Ihres Modus: Ein Beenden kann das Warten abbrechen, und Background-, Print- oder API-Key-Modi können anders reagieren.

Prüfen Sie das Repository, bevor Claude weiterarbeitet

Führen Sie im Repository-Root diese lesenden Befehle aus:

git status --short --branch
git diff --stat
git diff
git diff --cached
git ls-files --others --exclude-standard

/diff in Claude Code kann ebenfalls helfen, aber Git bleibt die Quelle der Wahrheit für den Working Tree.

Beantworten Sie vor der Fortsetzung fünf Fragen:

1. Welche Dateien wurden geändert?
2. Was ist staged, unstaged oder untracked?
3. Gibt es eine halbfertige Änderung, etwa einen neuen Aufruf ohne passende Typ-, Test- oder Migrationsanpassung?
4. Haben sich Lockfile, generierte Datei, Konfiguration oder Migration unerwartet verändert?
5. Welcher kleinste Befehl kann den wichtigsten Fehler jetzt sichtbar machen?

Führen Sie die echte Projektvalidierung aus:

# Beispiele: Verwenden Sie den kleinsten relevanten Befehl Ihres Repositories
npm test -- path/to/affected.test.ts
pytest tests/test_affected.py -q
cargo test affected_module
git diff --check

Ein sicherer Stopp bedeutet nicht „Claude hat eine Zusammenfassung geschrieben“. Er bedeutet: Sie können geänderte Dateien, Restarbeit, Testergebnis und den nächsten kleinen Schritt benennen.

Wenn der Diff unklar ist, fordern Sie nicht „alles fertig machen“. Sichern Sie zuerst den Checkpoint.

Erstellen Sie einen wiederherstellbaren Checkpoint auf eine von zwei Arten

Methode 1: geprüfter lokaler WIP-Commit

Nutzen Sie ihn, wenn der aktuelle Stand ausreichend kohärent ist und temporäre Commits auf einem lokalen Branch erlaubt sind.

git status --short --branch
git add -p
# Bereits geprüfte neue Dateien ausdrücklich hinzufügen.
git add -- path/to/reviewed-new-file
git diff --cached --check
git diff --cached
# Hier den kleinsten relevanten Test oder Lint ausführen.
git commit -m "WIP: checkpoint before Claude Code limit reset"
git rev-parse --short HEAD

Führen Sie git add -A nicht blind aus. Prüfen Sie .env, Zugangsdaten, private Fixtures, generierte Artefakte, große Binärdateien und Debug-Dumps. Ein lokaler WIP-Commit ist ein Wiederherstellungspunkt, keine Freigabe für den Push auf einen geschützten Branch.

Notieren Sie zusätzlich einen kurzen Handoff:

Ziel: Ablaufprüfung für Token-Expiry fertigstellen
Checkpoint: a1b2c3d
Geändert: auth_service.py, tests/test_auth.py
Validierung: gezielter Test schlägt fehl; erwartet 401, erhalten 200
Nächster Schritt: Expiry-Vergleich prüfen, bevor Callers geändert werden

Methode 2: Patches und geprüfte untracked Dateien außerhalb des Repositories

Verwenden Sie diese Methode, wenn Sie keinen Commit erzeugen möchten. Das Skript löst zuerst den tatsächlichen Pfad von CLAUDE_CHECKPOINT_DIR auf; liegt er im Repository, auch über einen symbolischen Link, bricht es ab, bevor Checkpoint-Dateien angelegt werden.

Der Ablauf hat drei Schritte: Zuerst prüfen Sie die staged-, unstaged- und untracked-Kandidaten samt Diffs, ohne etwas zu speichern. Danach wählen Sie pro Gruppe ausdrücklich die Pfadnummern aus; alles Nichtausgewählte wird damit ausdrücklich ausgeschlossen. Erst nach der Eingabe von SAVE REVIEWED wird geschrieben. Prüfen Sie vor der Auswahl den vollständigen Diff beziehungsweise die untracked-Datei und schließen Sie Schlüssel, private Daten und alles aus, was nicht gespeichert werden darf. Ist nur ein Teil einer Datei unbedenklich, teilen Sie die Änderung auf oder nutzen Sie den WIP-Commit oben, statt die ganze Datei auszuwählen.

Die externe Methode stoppt bei einer erkannten Umbenennung einer versionierten Datei; verwenden Sie dann einen geprüften WIP-Commit. Hat ein ausgewählter unstaged-Pfad auch staged-Änderungen, prüfen und sichern Sie beide Versionen. Setzen Sie checkpoint vor der Wiederherstellung auf das beim Speichern ausgegebene absolute Verzeichnis. Eine falsche Basis, ein verändertes Arbeitsverzeichnis oder ein fehlgeschlagener Schritt stoppt die Wiederherstellung.

repo_root="$(git rev-parse --show-toplevel)"
cd "$repo_root"

# Step 1: inspect everything. These commands do not save files.
git status --short --branch
git diff --cached
git diff
git ls-files --others --exclude-standard

# Steps 2-3: choose reviewed paths explicitly, then save only that scope.
python3 /dev/fd/3 3<<'PY'
from datetime import datetime, timezone
from pathlib import Path
import json, os, shlex, subprocess, tarfile


def git(*args):
    return subprocess.run(["git", *args], check=True, stdout=subprocess.PIPE).stdout


def path_list(*args):
    return list(dict.fromkeys(Path(os.fsdecode(x)) for x in git(*args).split(b"\0") if x))


def choose(label, items):
    print(f"\n{label} candidates:")
    if not items:
        print("  (none)")
        return []
    for i, path in enumerate(items, 1):
        print(f"  {i:>3}  {shlex.quote(os.fspath(path))}")
    answer = input(
        "Select reviewed numbers to save "
        "(1,3-5; 'all'; blank saves none): "
    ).strip().lower()
    if not answer:
        return []
    if answer == "all":
        return items[:]
    chosen = set()
    try:
        for token in answer.split(","):
            bounds = [int(x) for x in token.strip().split("-", 1)]
            chosen.update(range(min(bounds), max(bounds) + 1))
    except ValueError as exc:
        raise SystemExit("Invalid selection; nothing was saved.") from exc
    if not chosen or min(chosen) < 1 or max(chosen) > len(items):
        raise SystemExit("Selection is outside the displayed range; nothing was saved.")
    return [path for i, path in enumerate(items, 1) if i in chosen]


def patch(cached, items):
    if not items:
        return b""
    args = ["diff"] + (["--cached"] if cached else [])
    return git(*args, "--binary", "--", *(os.fspath(path) for path in items))


repo = Path(git("rev-parse", "--show-toplevel").decode().rstrip("\n")).resolve()
root = Path(os.environ.get(
    "CLAUDE_CHECKPOINT_DIR", os.fspath(Path.home() / "claude-checkpoints")
)).expanduser().resolve(strict=False)
if root == repo or repo in root.parents:
    raise SystemExit("CLAUDE_CHECKPOINT_DIR must resolve outside the repository.")
root.mkdir(parents=True, exist_ok=True)
root = root.resolve()
if root == repo or repo in root.parents:
    raise SystemExit("CLAUDE_CHECKPOINT_DIR must resolve outside the repository.")

# A path-only selection cannot represent both sides of a detected rename.
if (git("diff", "--cached", "--find-renames", "--diff-filter=R", "--name-only", "-z")
        or git("diff", "--find-renames", "--diff-filter=R", "--name-only", "-z")):
    raise SystemExit("Renames require a reviewed WIP commit; nothing was saved.")

candidates = {
    "staged": path_list("diff", "--cached", "--name-only", "-z"),
    "unstaged": path_list("diff", "--name-only", "-z"),
    "untracked": path_list("ls-files", "--others", "--exclude-standard", "-z"),
}
if not any(candidates.values()):
    raise SystemExit("No staged, unstaged, or untracked changes were found.")
selected = {name: choose(name, items) for name, items in candidates.items()}
if not any(selected.values()):
    raise SystemExit("No reviewed changes were selected; nothing was saved.")
missing_baseline = set(selected["unstaged"]) & (
    set(candidates["staged"]) - set(selected["staged"])
)
if missing_baseline:
    raise SystemExit(
        "Selected unstaged paths also have staged changes. Select both reviewed "
        "versions or use a WIP commit; nothing was saved."
    )

not_saved = {
    name: [path for path in candidates[name] if path not in selected[name]]
    for name in candidates
}

print("\nSelected for saving:")
for name, items in selected.items():
    print(f"  {name}: " + (", ".join(shlex.quote(os.fspath(p)) for p in items) or "(none)"))
print("Excluded and NOT saved:")
for name, items in not_saved.items():
    print(f"  {name}: " + (", ".join(shlex.quote(os.fspath(p)) for p in items) or "(none)"))
if input("Type SAVE REVIEWED to save exactly this scope: ").strip() != "SAVE REVIEWED":
    raise SystemExit("Confirmation did not match; nothing was saved.")

current = {
    "staged": path_list("diff", "--cached", "--name-only", "-z"),
    "unstaged": path_list("diff", "--name-only", "-z"),
    "untracked": path_list("ls-files", "--others", "--exclude-standard", "-z"),
}
if current != candidates:
    raise SystemExit("The candidate list changed during review; rerun from step 1.")

stamp = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%SZ")
checkpoint = (root / f"{repo.name}-claude-{stamp}").resolve(strict=False)
if checkpoint == repo or repo in checkpoint.parents:
    raise SystemExit("Checkpoint path unexpectedly resolves inside the repository.")
checkpoint.mkdir(exist_ok=False)
(checkpoint / "base-commit.txt").write_bytes(git("rev-parse", "HEAD"))
(checkpoint / "status.txt").write_bytes(git("status", "--short", "--branch"))
(checkpoint / "staged.patch").write_bytes(patch(True, selected["staged"]))
(checkpoint / "unstaged.patch").write_bytes(patch(False, selected["unstaged"]))
(checkpoint / "untracked.list0").write_bytes(b"".join(
    os.fsencode(os.fspath(path)) + b"\0" for path in selected["untracked"]
))

manifest = {
    "selected": {name: [os.fspath(p) for p in items] for name, items in selected.items()},
    "not_saved": {name: [os.fspath(p) for p in items] for name, items in not_saved.items()},
}
(checkpoint / "selection.json").write_text(
    json.dumps(manifest, ensure_ascii=True, indent=2) + "\n", encoding="utf-8"
)
omitted = [
    f"{name}\t{json.dumps(os.fspath(path), ensure_ascii=True)}"
    for name, items in not_saved.items() for path in items
]
(checkpoint / "not-saved.txt").write_text(
    "\n".join(omitted) + ("\n" if omitted else "(none)\n"), encoding="utf-8"
)
if selected["untracked"]:
    with tarfile.open(checkpoint / "untracked.tar.gz", "w:gz", dereference=False) as archive:
        for path in selected["untracked"]:
            archive.add(repo / path, arcname=path.as_posix(), recursive=False)

partial = bool(omitted)
(checkpoint / "scope.txt").write_text(
    "PARTIAL: see not-saved.txt; this is not a complete recovery point.\n"
    if partial else
    "REVIEWED SCOPE: every listed candidate was saved; ignored files remain outside scope.\n",
    encoding="utf-8",
)
print(("PARTIAL checkpoint" if partial else "Reviewed checkpoint") + f" saved to {checkpoint}")
if partial:
    print("Some listed changes were not saved; read not-saved.txt before recovery.")
PY

selection.json hält ausgewählte und ausgeschlossene Pfade fest, not-saved.txt listet jede Auslassung auf und scope.txt beschreibt den Umfang. Sobald ein staged-, unstaged- oder untracked-Kandidat ausgeschlossen wird, markieren Terminal und scope.txt das Ergebnis als PARTIAL; es ist dann kein vollständiger Wiederherstellungspunkt und stellt nur den ausgewählten Umfang wieder her. Ignored-Dateien bleiben außerhalb des Umfangs, und der Checkpoint beweist nicht, dass der Code funktioniert.

Lesen Sie vor der Wiederherstellung scope.txt und not-saved.txt. Stellen Sie in einem sauberen Checkout auf dem aufgezeichneten Base-Commit nur den gespeicherten Umfang wieder her:

(
    set -eu
    checkpoint="/absolute/path/printed-by-the-save-step" # Replace with the actual checkpoint directory.
    test -d "$checkpoint"
    repo_root="$(git rev-parse --show-toplevel)"
    cd "$repo_root"
    for required in base-commit.txt scope.txt not-saved.txt staged.patch unstaged.patch untracked.list0; do
        test -f "$checkpoint/$required"
    done
    cat "$checkpoint/scope.txt" "$checkpoint/not-saved.txt"
    test "$(git rev-parse HEAD)" = "$(cat "$checkpoint/base-commit.txt")"
    test -z "$(git status --porcelain --untracked-files=all)"
    if [ -s "$checkpoint/staged.patch" ]; then
        git apply --index "$checkpoint/staged.patch"
    fi
    if [ -s "$checkpoint/unstaged.patch" ]; then
        git apply "$checkpoint/unstaged.patch"
    fi
    if [ -s "$checkpoint/untracked.list0" ]; then
        tar -xzkf "$checkpoint/untracked.tar.gz"
    fi
    git status --short
)

Wenn das Repository nicht mehr auf dieser Basis steht, erzwingen Sie die Patches nicht. Erstellen Sie einen sauberen Branch oder Worktree am gespeicherten Commit, stellen Sie dort wieder her und integrieren Sie bewusst.

Nutzen Sie Claude-Code-Checkpoints, aber nicht statt Git

Die offizielle Checkpointing-Dokumentation erklärt, dass Claude Code direkte Dateiänderungen während der Sitzung verfolgt und über /rewind prüfen oder wiederherstellen kann. Beschrieben werden die 100 letzten Checkpoints einer Sitzung und ihre Bindung an die Conversation, sodass sie nach einem Resume verfügbar bleiben können.

Das ist nützlich, um einen schlechten Agent-Schritt rückgängig zu machen, aber kein Repository-Backup. Zu den dokumentierten Grenzen gehören Änderungen durch Bash, die meisten Subagent-Edits, parallele externe Änderungen sowie einige Symlink- und Hardlink-Fälle. Git bietet außerdem eine dauerhafte Commit-ID, Branches, prüfbare Patches und Wiederherstellung unabhängig von Claude.

Verwenden Sie beide Ebenen:

• /rewind für schnelles Zurücksetzen in der Sitzung;
• Git-Commit oder externes Bundle für einen dauerhaften Checkpoint.

Die CLI-Referenz dokumentiert:

claude -c
claude -r "<session>"

Führen Sie nach dem Resume erneut git status aus, bevor weitere Edits erlaubt werden. Eine wiederhergestellte Conversation beweist nicht, dass das Dateisystem noch dem alten Summary entspricht.

Entscheiden Sie erst nach dem Checkpoint zwischen Warten, Usage Credits und API

Situation	Erste Wahl	Warum
Reset nahe, Checkpoint sicher, Deadline erlaubt Pause	Warten	Keine zusätzliche verbrauchsabhängige Zahlung und kein Auth-Wechsel
Gleiche Oberfläche und Conversation nötig, gemessene Kosten akzeptabel	Usage Credits	Berechtigte Konten können nach dem enthaltenen Usage fortfahren
Separater Key, Provider-Saldo oder Projektbudget nötig	API	Abrechnung und Authentifizierung von der Subscription getrennt
Limits stören mehrere normale Arbeitstage	Plan und Workflow prüfen	Eine Unterbrechung rechtfertigt kein dauerhaftes Upgrade

Warten Sie, wenn die Pause günstiger als der Routenwechsel ist

Ist der Reset nah und der Checkpoint fertig, ist Warten meist sicherer. Notieren Sie die genaue Zeit und hinterlassen Sie den Handoff. Lassen Sie die Sitzung nur offen, wenn der Client ausdrücklich Warten und Fortsetzen anbietet.

Nach der Rückkehr:

git status --short --branch
git diff --stat

Formulieren Sie dann den nächsten Schritt. Ein bloßes „weiter“ zwingt den Agenten, den Zustand zu erraten.

Verwenden Sie Usage Credits, wenn Kontinuität am wichtigsten ist

Die Usage-Credits-Dokumentation beschreibt, dass berechtigte Pro- und Max-Nutzer zusätzliche Pay-as-you-go-Nutzung unter Settings > Usage aktivieren, Guthaben hinzufügen und Ausgaben steuern können. Die Abrechnung ist von der Subscription getrennt, und normale Fünf-Stunden-Fenster werden weiterhin zurückgesetzt.

Vor der Aktivierung:

• Monatslimit und Warnungen setzen;
• entscheiden, ob Auto-Reload akzeptabel ist;
• prüfen, dass die Oberfläche die Fortsetzung mit Usage Credits anzeigt;
• nach dem dringenden Checkpoint oder Akzeptanztest stoppen.

Das erhält Oberfläche und Kontext, ist aber kein kostenloses Überlaufkontingent.

Verwenden Sie eine API für getrennte Authentifizierung oder Budgets

Eine API ist ein anderer Authentifizierungs- und Abrechnungspfad. Sie übernimmt das Subscription-Kontingent nicht automatisch, und eine einzelne Umgebungsvariable ersetzt möglicherweise keinen gespeicherten Login. Prüfen Sie in Claude Code /status, bestätigen Sie Provider oder Gateway und suchen Sie den Request im Usage-Log des Anbieters.

BetterToken ist eine Anthropic-kompatible Pay-as-you-go-API, keine Erweiterung der Claude-Subscription. Sie kann für getrennten Key und Saldo relevant sein, aber Checkpoint und Handoff bleiben bei jedem Anbieter notwendig.

Vergleichen Sie API-Listenpreise desselben Modells, nicht die Gesamtkosten der Aufgabe

Die folgenden Standardpreise für Text-Tokens wurden am 2026-10-01 geprüft. Einheit: USD pro eine Million Tokens. Anthropic-Daten stammen von der offiziellen API-Preisseite, BetterToken-Daten von der Preisseite.

Exakte Modell-ID	Anthropic Input	Anthropic Output	BetterToken Input	BetterToken Output
claude-opus-5-5	$4.00	$20.00	$2.72	$13.60
claude-sonnet-5	$2.00	$10.00	$1.36	$6.80
claude-haiku-4-5-20251001	$1.00	$5.00	$0.68	$3.40

Die Tabelle vergleicht nur den Standardpreis für Input und Output derselben Modell-ID an diesem Datum. Sie macht diese Mechanismen nicht gleichwertig:

• Subscription Usage ist ein enthaltenes Kontingent mit Plan-Limits;
• Usage Credits sind verbrauchsabhängige Fortsetzung in berechtigten Claude-Oberflächen;
• API Usage wird einem separaten Konto nach Tokens und Funktionen berechnet.

Die tatsächlichen Aufgabenkosten hängen von Input-/Output-Tokens, Cache, Long Context oder Fast Mode, Retries, Tool Calls und Kontoregeln ab. Ein niedrigerer Listenpreis beweist nicht, dass die gesamte Aufgabe günstiger wird.

Setzen Sie mit einem prüfbaren Handoff fort, nicht nur mit „weiter“

Bereiten Sie einen kompakten Status vor:

Ziel: Was am Ende wahr sein muss
Base: Branch und Commit/Checkpoint-ID
Änderungen: staged, unstaged und untracked
Validierung: genaue Befehle und Ergebnisse
Bekannter Fehler: genaue Meldung oder Assertion
Nicht anfassen: sensible oder fremde Dateien
Nächste Aktion: ein kleiner testbarer Schritt

Lassen Sie Claude Code zuerst den aktuellen Diff prüfen und die geplante Aktion wiederholen. So werden ein anderer Branch, ein veraltetes Summary oder ein unvollständiger Stopp erkannt, bevor neue Änderungen entstehen.

Häufige Fragen

Erstellt der Graceful Stop automatisch einen Commit?

Nein. Die offizielle Aussage verspricht den Versuch eines sichereren Haltepunkts, keinen Git-Commit.

Garantiert er, dass die Aufgabe fertig ist?

Nein. Der Agent kann mit Restarbeit oder nur einem Teil der Änderungen stoppen. Tests und Akzeptanzkriterien entscheiden.

Kostet der Wrap-up zusätzlich?

Die angekündigte kleine feste Zuteilung stammt aus dem wöchentlichen Usage. Usage Credits und API sind separate gemessene Pfade; prüfen Sie den angezeigten Abrechnungsmodus.

Kann /rewind Git ersetzen?

Nein. Es hilft bei direkten Sitzungsänderungen, aber die dokumentierten Ausschlüsse decken nicht alle Repository-Änderungen ab.

Was gilt bei einem Weekly Limit?

Der Fünf-Stunden-Reset entfernt es möglicherweise nicht. Sichern Sie den Checkpoint, folgen Sie Limit-Typ und Zeit im Client und bestätigen Sie den blockierenden Zähler, bevor Sie zusätzliche Nutzung kaufen.