Claude Code beschleunigen: langsame Sitzungen systematisch optimieren

Claude Code war beim ersten Fehler noch schnell. Zwei Stunden später liegen Build-Ausgaben, mehrere fehlgeschlagene Versuche und ein halbes Repository im Gesprächsverlauf. Jede Rückfrage dauert länger, und Claude untersucht erneut Dateien, die mit dem Fehler nichts zu tun haben.

In dieser Situation hilft es wenig, nur ein anderes Modell zu wählen oder die Aufgabe noch einmal lauter zu formulieren. Zuerst muss klar sein, welcher Teil langsam ist: die erste Antwort, die Suche im Repository, ein Testlauf oder der gesamte Weg bis zu einer geprüften Änderung. Dieser Leitfaden zeigt einen messbaren Ablauf, der auch für Einsteiger funktioniert.

Das Wichtigste in fünf Punkten

1. Miss immer die Zeit bis zu einem geprüften Ergebnis, nicht nur die Zeit bis zur ersten Textausgabe.
2. Nutze /context, um belegten Kontext zu erkennen, und /compact mit einem klaren Erhaltungsauftrag.
3. Begrenze jeden Auftrag durch Dateien, Verzeichnisse, Akzeptanzkriterien und einen passenden Test.
4. Halte CLAUDE.md kurz; wiederkehrende Spezialabläufe gehören in bei Bedarf geladene Skills.
5. Entferne niemals Tests oder Reviews, nur um einen Lauf schneller aussehen zu lassen.

Was bedeutet „langsam“ bei Claude Code?

Drei verschiedene Probleme werden oft vermischt:

Beobachtung	Wahrscheinliche Ursache	Erste Prüfung
Die Antwort beginnt spät	großer oder unübersichtlicher Kontext, aufwendige Werkzeuge	/context ausführen
Claude liest sehr viele Dateien	Auftrag ohne klaren Bereich	Dateien und Ausschlüsse nennen
Der Agent arbeitet lange nach der ersten Antwort	langsamer Build, breite Tests, viele Wiederholungen	Befehlsdauer separat messen
Nach mehreren Aufgaben sinkt die Qualität	alte Entscheidungen und Ausgaben verdrängen relevante Hinweise	Aufgabe abschließen, dann /clear oder gezielt /compact
Die Kosten steigen, obwohl die Aufgabe gleich bleibt	lange Sitzungen und wiederholt übertragener Kontext	/usage und Sitzungsgrenzen prüfen

Die offizielle Dokumentation erklärt, dass Claude Code lange Verläufe automatisch verdichtet. Das verhindert jedoch nicht, dass irrelevante Dateien und Werkzeugausgaben vorher Platz belegen. Mit /context siehst du die aktuelle Aufteilung. Die Befehlsübersicht beschreibt außerdem /compact, /clear, /usage und weitere Diagnosebefehle.

Schritt 1: Vor jeder Optimierung einen Ausgangswert erfassen

Starte nicht mit zehn Änderungen gleichzeitig. Wähle eine typische, ungefährliche Aufgabe, etwa einen bekannten fehlgeschlagenen Test. Notiere vier Werte:

• Zeit bis zur ersten sinnvollen Rückmeldung
• Gesamtzeit bis zum abgeschlossenen Test
• Zahl der geänderten Dateien
• Ergebnis des vorgesehenen Prüfkommandos

Die folgenden Befehle werden innerhalb einer interaktiven Claude-Code-Sitzung eingegeben. Sie sind keine Bash-Befehle:

/usage
/context
/compact Behalte geänderte Dateien, fehlgeschlagene Tests, getroffene Entscheidungen und offene Risiken bei.

/usage zeigt die für die jeweilige Umgebung verfügbaren Nutzungsinformationen. /context zeigt, was das Kontextfenster belegt. /compact fasst den bisherigen Verlauf zusammen; der Zusatz legt fest, welche Informationen in der Zusammenfassung besonders wichtig sind. Bei einem Wechsel zu einer völlig anderen Aufgabe ist /clear meist eindeutiger als eine weitere Verdichtung.

Schritt 2: Den Auftrag so klein wie die Entscheidung machen

„Finde den Fehler im Projekt“ zwingt Claude zunächst zu einer breiten Suche. Ein guter Auftrag benennt dagegen den sichtbaren Fehler, den erlaubten Bereich und den Nachweis. Das spart nicht nur Kontext, sondern macht eine falsche Änderung schneller erkennbar.

claude -p "Behebe ausschließlich den Nullwertfehler in src/api/auth.ts.
Lies zuerst src/api/auth.ts und tests/auth.test.ts.
Ändere keine anderen Dateien und ignoriere node_modules, dist und coverage.
Führe npm test -- tests/auth.test.ts aus.
Nenne danach geänderte Dateien, Prüfergebnis und verbleibende Risiken."

Vier Grenzen sind besonders nützlich:

1. Dateigrenze: Welche Dateien darf Claude lesen und ändern?
2. Entscheidungsgrenze: Soll Claude nur analysieren oder auch implementieren?
3. Prüfgrenze: Welcher kleine Test beweist die Änderung zuerst?
4. Abbruchgrenze: Wann soll Claude stoppen und eine Rückfrage stellen?

Der Mensch entscheidet über Geschäftslogik, Sicherheitsfolgen und akzeptable Risiken. Claude Code kann Dateien finden, eine kleine Änderung umsetzen, Tests ausführen und den Nachweis zusammenfassen. Diese Trennung verhindert, dass ein Performance-Auftrag unbemerkt zu einem großen Refactoring wird. Die genannten Grenzen beschreiben allerdings den Auftrag; sie sind noch keine technisch erzwungenen Zugriffsgrenzen.

Schritt 3: CLAUDE.md als Wegweiser statt als Wissensarchiv nutzen

Eine lange CLAUDE.md wird bei jeder passenden Sitzung wieder relevant. Dort gehören nur Hinweise hinein, die fast jede Aufgabe benötigt: zentrale Befehle, wichtige Verzeichnisse, Arbeitsanforderungen und die gewünschte Prüfform. Seltene Deploy-Abläufe oder ausführliche Checklisten sind in einem Skill besser aufgehoben, weil dessen Inhalt erst bei Bedarf geladen wird. Das entspricht der offiziellen Empfehlung zu Projektgedächtnis und Skills.

# CLAUDE.md

## Projektbefehle
- Build: npm run build
- Tests: npm test
- Typprüfung: npm run typecheck

## Orientierung
- API: src/api/
- Oberfläche: src/components/
- Tests: tests/

## Sicherheitsanforderungen
- Keine Zugangsdaten ausgeben oder verändern.
- Keine Produktionsmigration ohne ausdrückliche Freigabe ausführen.

## Hinweise für die Verdichtung
- Geänderte Dateien, fehlgeschlagene Befehle, Entscheidungen und nächste Schritte behalten.

Prüfe die Datei einmal im Monat. Entferne abgeschlossene Störungen, veraltete Pfade und Regeln, die nur ein einzelnes Modul betreffen. Pfadspezifische Regeln können in .claude/rules/ liegen; lange, wiederkehrende Abläufe passen in einen Skill.

CLAUDE.md ist keine Zugriffskontrolle

Die beiden Sicherheitszeilen im Beispiel sind Hinweise an das Modell. CLAUDE.md wird als Kontext geladen und kann Verhalten lenken, aber keinen Dateizugriff oder Shell-Befehl technisch verhindern. Verlasse dich deshalb nicht darauf, dass ein Satz wie „kein git push“ eine Produktionsumgebung schützt.

Für echte Schranken nennt die offizielle Dokumentation drei getrennte Ebenen:

• Berechtigungsregeln erlauben, erfragen oder verweigern Werkzeuge und konkrete Befehlsmuster. Eine deny-Regel hat Vorrang vor ask und allow.
• Ein PreToolUse-Hook kann einen Werkzeugaufruf vor seiner Ausführung prüfen und blockieren. Das eignet sich etwa für geschützte Dateien oder organisationsspezifische Regeln.
• Die Sandbox begrenzt Shell-Prozesse auf Betriebssystemebene. Auf nativem Windows wird sie nicht unterstützt; dort sind WSL2, ein Container oder eine virtuelle Maschine die belastbarere Grenze.

Zusätzlich sollten Produktionszugänge unter einem eigenen Betriebssystemkonto mit minimalen Rechten liegen. Ein temporärer Git-Worktree schützt nur den Quellstand des Hauptarbeitsbaums. Er verhindert weder Netzwerkzugriffe noch Änderungen außerhalb des Repositorys.

Schritt 4: Werkzeugausgaben verkleinern, ohne Beweise zu verlieren

Ein vollständiges Build-Protokoll mit Tausenden erfolgreichen Zeilen bringt selten zusätzlichen Nutzen. Trotzdem darf der eigentliche Fehler nicht abgeschnitten werden. Lass zuerst den engsten Test laufen und erweitere danach die Prüfung.

Ein sinnvoller Ablauf für einen TypeScript-Fehler lautet:

npm test -- tests/auth.test.ts
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }

npm run typecheck
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }

npm test
exit $LASTEXITCODE

Die Reihenfolge liefert früh eine verwertbare Rückmeldung. Sie ersetzt nicht die vollständige Prüfung vor dem Merge. Bei besonders lauten Werkzeugen kannst du die Ausgabe in eine Datei schreiben und Claude nur die Fehlermeldung plus einige Zeilen Kontext lesen lassen. Bewahre das vollständige Protokoll für die menschliche Kontrolle auf.

Auch MCP-Server können Kontext und Laufzeit beeinflussen. Mit /mcp lässt sich prüfen, welche Server aktiv sind. Deaktiviere einen Server nicht pauschal: Kläre zuerst, ob die Aufgabe seine Daten wirklich benötigt und ob eine direkte Datei- oder API-Abfrage denselben Nachweis günstiger liefert.

Schritt 5: Breiten und begrenzten Auftrag vergleichbar messen

Der folgende PowerShell-Versuch misst zwei Auftragsvarianten. Speichere ihn als Measure-ClaudePrompt.ps1 in einem vertrauenswürdigen Test-Repository. Übergib einen bekannten Fehler sowie ein Verifikationsprogramm mit getrennten Argumenten; das Skript wertet keine zusammengesetzte Shell-Zeichenkette aus.

Jeder Lauf erhält einen neuen, abgetrennten Git-Worktree vom selben HEAD. Nicht eingecheckte Änderungen des Ausgangsarbeitsbaums werden absichtlich nicht übernommen. Claude darf nur Dateien innerhalb dieses Worktrees lesen und bearbeiten. Shell-, MCP- und Browser-Werkzeuge sind für die Agentensitzung gesperrt. Projektbezogene CLAUDE.md-Hinweise und Hooks bleiben dagegen aktiv und gelten damit für beide Varianten unter denselben Bedingungen. Führe den Versuch deshalb nur in einem vertrauenswürdigen Test-Repository aus. Das Skript verwendet dokumentierte Optionen wie --tools, --disallowedTools und --max-turns; eine ältere CLI meldet unbekannte Optionen beim Aufruf. Die verfügbaren Optionen stehen in der offiziellen CLI-Referenz. Der angegebene Test und git status laufen danach außerhalb der Agentensitzung im temporären Worktree. Ihre Dauer und Exitcodes gehören zum Ergebnis.

param(
  [Parameter(Mandatory = $true)]
  [string]$BroadPrompt,

  [Parameter(Mandatory = $true)]
  [string]$ScopedPrompt,

  [Parameter(Mandatory = $true)]
  [string]$VerifyExecutable,

  [string[]]$VerifyArguments = @(),

  [ValidateRange(1, 10)]
  [int]$RepeatCount = 3,

  [ValidateRange(0.05, 10)]
  [decimal]$MaxBudgetUsd = 1.00
)

Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"

[void](Get-Command git -ErrorAction Stop)
[void](Get-Command claude -ErrorAction Stop)
[void](Get-Command $VerifyExecutable -ErrorAction Stop)

$budgetText = $MaxBudgetUsd.ToString(
  [Globalization.CultureInfo]::InvariantCulture
)

$repository = (& git rev-parse --show-toplevel).Trim()
if ($LASTEXITCODE -ne 0 -or -not $repository) {
  throw "Dieses Skript muss in einem Git-Repository laufen."
}

$baseline = (& git -C $repository rev-parse HEAD).Trim()
if ($LASTEXITCODE -ne 0 -or -not $baseline) {
  throw "HEAD konnte nicht bestimmt werden."
}

$runRoot = Join-Path ([IO.Path]::GetTempPath()) (
  "claude-speed-{0}" -f [guid]::NewGuid().ToString("N")
)
$logDir = Join-Path $runRoot "logs"
[void](New-Item -ItemType Directory -Path $logDir -Force)

$activeWorktrees = [Collections.Generic.List[string]]::new()

function Remove-BenchmarkWorktree {
  param([Parameter(Mandatory = $true)][string]$Path)

  $rootPrefix = [IO.Path]::GetFullPath($runRoot) +
    [IO.Path]::DirectorySeparatorChar
  $target = [IO.Path]::GetFullPath($Path)
  if (-not $target.StartsWith(
    $rootPrefix,
    [StringComparison]::OrdinalIgnoreCase
  )) {
    throw "Unsicherer Worktree-Pfad: $target"
  }

  & git -C $repository worktree remove --force $target | Out-Null
  if ($LASTEXITCODE -ne 0) {
    throw "Worktree konnte nicht entfernt werden: $target"
  }

  [void]$activeWorktrees.Remove($Path)
}

$runs = @(
  [pscustomobject]@{ Name = "breit"; Prompt = $BroadPrompt }
  [pscustomobject]@{ Name = "begrenzt"; Prompt = $ScopedPrompt }
)

$results = [Collections.Generic.List[object]]::new()

try {
  foreach ($iteration in 1..$RepeatCount) {
    foreach ($run in $runs) {
      $fixture = Join-Path $runRoot (
        "{0}-{1}-repo" -f $run.Name, $iteration
      )

      & git -C $repository worktree add --detach $fixture $baseline |
        Out-Null
      if ($LASTEXITCODE -ne 0) {
        throw "Temporärer Worktree konnte nicht erstellt werden."
      }
      $activeWorktrees.Add($fixture)

      $claudeLog = Join-Path $logDir (
        "{0}-{1}-claude.log" -f $run.Name, $iteration
      )
      $verifyLog = Join-Path $logDir (
        "{0}-{1}-verify.log" -f $run.Name, $iteration
      )
      $agentPrompt = $run.Prompt + @"

Arbeite nur im aktuellen Arbeitsbaum. Erstelle keinen Commit und führe
keinen Push oder Deploy aus. Die Verifikation erfolgt nach deiner Sitzung.
"@

      $claudeArgs = @(
        "-p"
        "--permission-mode"; "dontAsk"
        "--tools"; "Edit,Read,Glob,Grep,Write"
        "--allowedTools"; "Read(./**)"; "Edit(./**)"
        "--disallowedTools"; "mcp__*"
        "--strict-mcp-config"
        "--no-chrome"
        "--no-session-persistence"
        "--max-budget-usd"; $budgetText
        "--max-turns"; "12"
      )
      $claudeArgs += $agentPrompt

      $watch = [Diagnostics.Stopwatch]::StartNew()
      Push-Location $fixture
      try {
        & claude @claudeArgs 2>&1 |
          Tee-Object -FilePath $claudeLog |
          Out-Null
        $claudeExit = $LASTEXITCODE

        & $VerifyExecutable @VerifyArguments 2>&1 |
          Tee-Object -FilePath $verifyLog |
          Out-Null
        $verifyExit = $LASTEXITCODE

        $changes = @(& git status --short)
        if ($LASTEXITCODE -ne 0) {
          throw "Git-Status konnte nicht gelesen werden."
        }
      }
      finally {
        Pop-Location
        $watch.Stop()
      }

      $results.Add([pscustomobject]@{
        Variante = $run.Name
        Wiederholung = $iteration
        SekundenBisZurPruefung = [math]::Round(
          $watch.Elapsed.TotalSeconds,
          1
        )
        ClaudeExitcode = $claudeExit
        PruefungExitcode = $verifyExit
        GeaenderteDateien = $changes.Count
        ClaudeProtokoll = $claudeLog
        Pruefprotokoll = $verifyLog
      })

      Remove-BenchmarkWorktree -Path $fixture
    }
  }
}
finally {
  foreach ($fixture in @($activeWorktrees)) {
    try {
      Remove-BenchmarkWorktree -Path $fixture
    }
    catch {
      Write-Warning $_
    }
  }
  & git -C $repository worktree prune
}

$csv = Join-Path $runRoot "results.csv"
$results | Export-Csv -Path $csv -NoTypeInformation -Encoding utf8
$results | Format-Table -AutoSize
Write-Host "Protokolle und CSV: $runRoot"

Ein Aufruf für das Beispiel sieht so aus:

.\Measure-ClaudePrompt.ps1 `
  -BroadPrompt "Behebe den Fehler bei der Anmeldung." `
  -ScopedPrompt "Behebe nur den Nullwertfehler in src/api/auth.ts. Lies zuerst tests/auth.test.ts und ändere höchstens diese beiden Dateien." `
  -VerifyExecutable "npm" `
  -VerifyArguments @("test", "--", "tests/auth.test.ts")

Ein einzelner Lauf ist kein belastbarer Vergleich: Modellantworten, Cache-Zustand und Netzlast schwanken. Das Skript wiederholt deshalb standardmäßig jede Variante dreimal. Vergleiche nur Läufe mit PruefungExitcode = 0, kontrolliere die erzeugten Protokolle und bilde anschließend den Median von SekundenBisZurPruefung.

Die Dateifreigaben begrenzen nur Claude Code und gelten relativ zum jeweiligen temporären Worktree. Das extern gestartete Verifikationsprogramm läuft dagegen mit den Rechten des aufrufenden Kontos. Prüfe daher vorher das zugehörige Testskript und verwende keine Produktionszugänge. Für eine harte Begrenzung gehört der gesamte Versuch in einen Container, eine virtuelle Maschine oder unter WSL2 mit aktivierter Sandbox. Wird der PowerShell-Prozess hart beendet, kontrolliere mit git worktree list verbliebene Einträge und entferne ausschließlich die dort ausgewiesenen temporären Worktrees.

Drei praktische Anwendungsfälle

1. Kleiner Fehler in einer API

Gib Claude den fehlgeschlagenen Test, die betroffene Datei und das erwartete Verhalten. Lass zuerst nur diesen Test laufen. Der Mensch prüft anschließend, ob der Fehler tatsächlich ein Nullwertproblem ist oder ob etwa eine fehlende Berechtigungsprüfung dahinterliegt.

Geeigneter Auftrag: „Analysiere src/api/auth.ts und tests/auth.test.ts. Ändere erst nach einer kurzen Ursachenbeschreibung. Stoppe, falls Authentifizierung oder Datenmodell angepasst werden müssten.“

2. Größeres Refactoring

Trenne die Arbeit in Bestandsaufnahme, Plan, kleine Änderung und Verifikation. Nach jeder abgeschlossenen Phase kann /compact mit einem Fokus auf Entscheidungen und offene Risiken verwendet werden. Ein Subagent eignet sich für eine klar abgegrenzte Recherche, zum Beispiel alle Aufrufer einer veralteten Funktion. Die Hauptsitzung behält nur Ergebnis, Fundstellen und Entscheidung.

Nicht delegieren: Freigaben für Datenmigrationen, öffentliche API-Brüche oder Änderungen an Berechtigungen. Diese Entscheidungen brauchen einen Menschen und einen nachvollziehbaren Review.

3. Mehrsprachige Content-Pipeline

Übersetzung, Linkprüfung und Qualitätsprüfung erzeugen viel Text. Bearbeite deshalb eine Sprache oder einen Artikel pro Agent und gib eine feste Dateiliste vor. Die Hauptsitzung prüft Metadaten, interne Links, Build und Veröffentlichung. So landet nicht jede vollständige Übersetzung im selben Kontext.

Abbruchregel: Wenn ein Agent außerhalb der erlaubten Datei ändert, wird nicht weitergebaut. Zuerst werden Diff und Arbeitsbaum geprüft. Diese Regel spart mehr Zeit als ein späteres Aufräumen vermischter Änderungen.

Häufige Fallstricke und ihre Korrektur

Zu früh das Modell wechseln

Ein größeres Kontextfenster kann eine lange Sitzung aufnehmen, entfernt aber keine irrelevanten Informationen. Prüfe zuerst /context, räume den Auftrag auf und miss erneut. Ein Modellwechsel ist erst danach ein sinnvoller Vergleich.

/compact ohne Fokus ausführen

Eine allgemeine Zusammenfassung kann genau den fehlgeschlagenen Befehl oder die noch ungeprüfte Annahme verkürzen. Nenne beim Verdichten ausdrücklich Dateien, Entscheidungen, Fehler und nächste Schritte. Bei einem Themenwechsel ist /clear die sauberere Grenze.

Jede Regel in CLAUDE.md sammeln

Wenn Incident-Berichte, lange Architekturerklärungen und seltene Deploy-Schritte dauerhaft geladen werden, konkurrieren sie mit dem aktuellen Code. Behalte dort nur wiederkehrende Leitplanken und verschiebe Detailabläufe in Skills oder verlinkte Dokumentation.

Verifikation für Geschwindigkeit opfern

Ein Lauf ohne Tests ist nicht schneller abgeschlossen, sondern nur früher abgebrochen. Nutze gestufte Prüfungen: betroffener Test, Typprüfung, vollständige Tests. Miss die Gesamtzeit bis zum belastbaren Ergebnis.

Subagents für winzige Aufgaben einsetzen

Ein Agent braucht einen eigenen Auftrag und liefert eine Übergabe. Für das Umbenennen einer Variablen ist dieser Aufwand größer als der Nutzen. Delegiere nur klar abtrennbare Recherche oder parallele Prüfungen mit einem erwarteten Ergebnisformat.

Eine kurze Checkliste für die nächste langsame Sitzung

• /context ausgeführt und größten Verbraucher notiert
• aktuelle Aufgabe von früheren Aufgaben getrennt
• erlaubte Dateien und ausgeschlossene Verzeichnisse genannt
• kleinsten aussagekräftigen Test festgelegt
• CLAUDE.md auf dauerhaft nötige Regeln begrenzt
• große Recherche nur mit klarer Rückgabe delegiert
• Zeit bis zum geprüften Ergebnis gemessen
• vollständige Verifikation vor dem Merge beibehalten

Vertiefend helfen der Leitfaden zur Token-Optimierung, die Anleitung zum Kontextmanagement und der Berechtigungsleitfaden.

Claude Code im Team verbindlich schneller einsetzen

Wenn mehrere Entwickler unterschiedliche Prompts, CLAUDE.md-Regeln und Prüfabläufe verwenden, reicht ein einzelner Tipp nicht. In der Claude-Code-Schulung und Beratung wird aus einem echten Repository ein begrenzter Arbeitsablauf mit Messwerten, Sicherheitsgrenzen und wiederholbarer Verifikation aufgebaut.

Tatsächlich geprüft

Für diese Überarbeitung wurden die aktuellen offiziellen Seiten zu Kontextfenster, Befehlen, Kosten, Projektgedächtnis und Skills abgeglichen. Die PowerShell-Beispiele wurden auf syntaktische Gültigkeit und eindeutige Exitcodes geprüft. Es wurde kein allgemeiner Geschwindigkeitsgewinn behauptet: Die tatsächliche Verbesserung hängt vom Repository, den verwendeten Werkzeugen, der Netzverbindung und der Aufgabenart ab und muss mit dem beschriebenen Vorher-Nachher-Versuch gemessen werden.