Plan & Thinking Mode

Level 3 | 35 Minuten

Nutze Extended Thinking und Plan Mode für komplexe Aufgaben

Lernziele

• Extended Thinking und Budget Tokens verstehen
• Plan Mode für strukturierte Problemlösung einsetzen
• Thinking + Plan Mode kombinieren
• Wann welchen Modus nutzen

Extended Thinking erklärt

Extended Thinking ist eine der leistungsstärksten Funktionen von Claude Code. Sie gibt dem Modell ein dediziertes Token-Budget zum Nachdenken — BEVOR es die eigentliche Antwort formuliert. Das Ergebnis: Deutlich durchdachtere, gründlichere und korrektere Antworten, besonders bei komplexen Aufgaben. Die Analogie: Stell dir vor, du stellst einem Experten eine komplexe Frage. Antwort A: Er antwortet sofort aus dem Bauch heraus. Antwort B: Er nimmt sich 5 Minuten Bedenkzeit, macht sich Notizen, wägt Optionen ab, und antwortet dann. Antwort B ist fast immer besser — und genau das macht Extended Thinking für Claude. Technisch erzeugt Claude bei aktiviertem Extended Thinking zuerst einen internen Thinking-Block. Diese Gedanken sind für dich normalerweise nicht sichtbar, beeinflussen aber die Qualität der Antwort erheblich. Claude analysiert das Problem, identifiziert Fallstricke, erwägt Alternativen und strukturiert dann erst die Antwort. Die Aktivierung erfolgt über Schlüsselwörter: 'think' für moderate Tiefe, 'think hard' für intensive Analyse, 'ultrathink' für maximales Reasoning. Alternativ über die Umgebungsvariable MAX_THINKING_TOKENS oder den /think Befehl. Der Effekt ist messbar: Bei einfachen Fragen macht Extended Thinking kaum einen Unterschied (Claude 'weiß' die Antwort sofort). Bei komplexen Architektur-Fragen, Multi-Datei-Refactorings oder schwierigen Algorithmen verbessert sich die Qualität um geschätzt 30-60%. Besonders die Behandlung von Edge Cases und die Konsistenz über mehrere Dateien hinweg profitieren. Der Trade-off: Thinking-Tokens kosten genauso wie Output-Tokens. 'ultrathink' kann schnell 50.000+ Tokens verbrauchen. Nutze Extended Thinking gezielt für Aufgaben wo der Qualitätsgewinn die Mehrkosten rechtfertigt.

💡 Schlüsselkonzept Extended Thinking ist KEIN anderes Modell. Es ist dasselbe Modell, das sich mehr Zeit nimmt. Wie der Unterschied zwischen "schnell antworten" und "gründlich nachdenken" bei einem Menschen.

Wie Extended Thinking funktioniert

Extended Thinking gibt Claude ein separates Token-Budget zum Nachdenken BEVOR es seine eigentliche Antwort formuliert. Stell dir vor, Claude schreibt sich erst private Notizen auf einen Schmierzettel — analysiert das Problem, erwägt Alternativen, identifiziert Fallstricke — und formuliert dann erst die eigentliche Antwort basierend auf diesen Überlegungen. Technisch funktioniert es so: Wenn Extended Thinking aktiviert ist, generiert Claude zuerst einen internen Thinking-Block. Diese Gedanken sind für dich normalerweise nicht sichtbar (außer im Verbose-Modus), aber sie beeinflussen die Qualität der Antwort erheblich. Je mehr Tokens dem Thinking reserviert sind, desto gründlicher die Analyse. Der Effekt ist besonders bei komplexen Aufgaben messbar: Bei einfachen Fragen ('Was macht diese Funktion?') macht Extended Thinking kaum einen Unterschied. Bei komplexen Architekturproblemen ('Wie sollten wir die Authentifizierung redesignen um gleichzeitig SSO, MFA und API-Keys zu unterstützen?') ist der Qualitätssprung dramatisch. In Claude Code aktivierst du Extended Thinking über Schlüsselwörter im Prompt: 'think' für moderate Tiefe, 'think hard' für intensives Nachdenken, 'ultrathink' für maximales Reasoning. Du kannst auch die Umgebungsvariable MAX_THINKING_TOKENS setzen um ein festes Budget zu definieren. Der Kosten-Aspekt: Thinking-Tokens kosten genauso wie Output-Tokens. 'think' fügt vielleicht 1.000-5.000 Thinking-Tokens hinzu, 'ultrathink' kann 50.000+ kosten. Bei Opus-Preisen bedeutet ultrathink schnell 0.50-1.00 USD pro Anfrage. Nutze es gezielt. Ein wichtiger Unterschied zum Plan Mode: Extended Thinking passiert innerhalb einer einzelnen Anfrage. Plan Mode ist ein separater Modus der über mehrere Nachrichten hinweg funktioniert. Extended Thinking verbessert die Qualität einer Antwort, Plan Mode verhindert voreilige Aktionen. Mein Rat: Mache Extended Thinking zu deinem Standard-Werkzeug für alles was über einfache Edits hinausgeht. 'think' kostet wenig und verbessert die Qualität spürbar.

EXTENDED THINKING ABLAUF
━━━━━━━━━━━━━━━━━━━━━━━

1. Dein Prompt kommt an
   ↓
2. Claude erstellt "Thinking Blocks" (intern)
   → Zerlegt das Problem
   → Plant eine Strategie
   → Entwirft und kritisiert Lösungen
   → Bewertet Alternativen
   ↓
3. Thinking Summary wird zurückgegeben
   → Du siehst eine Zusammenfassung des Denkprozesses
   ↓
4. Finale Antwort basiert auf dem Reasoning

THINKING BUDGET (API):
{
  "thinking": {
    "type": "enabled",
    "budget_tokens": 5000
  }
}

BUDGET-EMPFEHLUNGEN:
~1.000 Tokens  → Einfache Architektur-Entscheidungen
~5.000 Tokens  → Komplexe System-Design Fragen
~10.000 Tokens → Kritische Sicherheits-Analysen
~64.000 Tokens → Maximale Analyse (z.B. Proof-System Design)

Plan Mode in Claude Code

Plan Mode schaltet Claude in einen reinen Analyse-Modus: Es liest, denkt und plant, macht aber KEINE Code-Änderungen. Das ist perfekt wenn du erst eine Strategie entwickeln willst bevor du die erste Zeile Code anfasst — besonders bei komplexen Aufgaben wo ein falscher Ansatz stundenlangen Rework bedeutet. Du aktivierst Plan Mode mit /plan oder indem du es in deinem Prompt sagst. Im Plan Mode hat Claude weiterhin Zugriff auf Read, Grep, Glob und andere Analyse-Tools, aber Write, Edit und Bash sind gesperrt. Claude kann dein Projekt vollständig analysieren ohne etwas zu verändern. Ein typischer Plan-Mode Workflow: Du fragst 'Wie würdest du die User-Authentifizierung von Sessions auf JWT umstellen?' Claude analysiert die aktuelle Implementation, identifiziert alle betroffenen Dateien, erstellt einen Schritt-für-Schritt Migrationsplan, listet Risiken und Edge Cases auf, und schlägt eine Teststrategie vor — ohne eine einzige Zeile zu ändern. Der Vorteil: Du kannst den Plan prüfen, Fragen stellen, Anpassungen vornehmen und mit Kollegen diskutieren bevor die Implementation beginnt. Wenn der Plan nicht überzeugt, hast du nichts kaputt gemacht. Wenn er gut ist, hast du eine klare Roadmap. Nach der Planung wechselst du zurück in den normalen Modus und sagst 'Setze den Plan um'. Claude hat den gesamten Plan noch im Kontext und kann ihn systematisch abarbeiten. Plan Mode ist besonders wertvoll für: Architektur-Entscheidungen, große Refactorings, Datenmigrationem, Security-Audits, und Performance-Optimierungen. Für einfache Bug-Fixes oder kleine Features ist er Overhead. Ein Profi-Tipp: Nutze Plan Mode am Anfang eines neuen Projekts oder wenn du in eine unbekannte Codebase einsteigst. 'Analysiere die Projektstruktur und erkläre die Architektur' im Plan Mode gibt dir einen perfekten Überblick ohne Risiko.

PLAN MODE AKTIVIEREN
━━━━━━━━━━━━━━━━━━━

Methode 1: Shift+Tab (2x drücken)
→ Wechselt in Plan Mode
→ Claude analysiert BEVOR es implementiert

Methode 2: Im Prompt
> "Plan this first, don't implement yet"
> "Create a plan for..."

WAS PLAN MODE MACHT:
┌──────────────┐     ┌──────────────┐
│   EXPLORE    │ ──→ │    PLAN      │
│ Codebase     │     │ Architektur  │
│ analysieren  │     │ entwerfen    │
└──────────────┘     └──────┬───────┘
                            │
                            ▼
                     ┌──────────────┐
                     │   REVIEW     │
                     │ User prüft   │
                     │ den Plan     │
                     └──────┬───────┘
                            │
                            ▼
                     ┌──────────────┐
                     │   EXECUTE    │
                     │ Implementie- │
                     │ rung starten │
                     └──────────────┘

Thinking Trigger Keywords

Bestimmte Schlüsselwörter in deinem Prompt aktivieren verschiedene Stufen des Extended Thinking. Claude Code erkennt diese Wörter und reserviert entsprechend viele Tokens für internes Reasoning. Die Wahl des richtigen Keywords ist ein einfacher aber wirkungsvoller Qualitätshebel. Die Standard-Keywords von niedrig nach hoch: 'think' aktiviert ein moderates Thinking-Budget. Claude denkt kurz nach bevor es antwortet. Gut für Code-Analyse, Bug-Suche und mittelkomplexe Implementierungen. 'think step by step' ist ähnlich, betont aber die schrittweise Analyse. 'think hard' reserviert ein deutlich höheres Budget. Claude analysiert das Problem aus mehreren Perspektiven und erwägt Alternativen. Gut für Architekturentscheidungen, komplexe Refactorings und schwierige Bugs. 'ultrathink' ist die Maximum-Stufe. Claude investiert massiv in internes Reasoning — vergleichbar mit einem Experten der sich einen halben Tag mit dem Problem beschäftigt. Reserviere das für wirklich schwierige Probleme: System-Design, komplexe Algorithmen, Security-Architektur. Du kannst die Keywords natürlich in deine normalen Sätze einbauen: 'Think hard über die beste Datenbankstruktur für unser Benachrichtigungssystem.' 'Ultrathink: Wie können wir die Race Condition im Payment-Prozess lösen?' Ein wichtiger Hinweis: Die Keywords funktionieren auch in Kombination mit anderen Patterns. 'Think hard als Security-Auditor: Analysiere die Input-Validierung' kombiniert Extended Thinking mit dem Persona-Pattern für maximale Tiefe. Kostenbeispiele: 'think' bei einer typischen Anfrage: +0.01-0.05 USD. 'think hard': +0.05-0.20 USD. 'ultrathink': +0.20-1.00+ USD. Die genauen Kosten hängen von der Komplexität der Antwort ab. Faustregel: Nutze 'think' als Standard für alles was nicht trivial ist. 'think hard' für wichtige Entscheidungen. 'ultrathink' für die schwierigsten 5% deiner Aufgaben.

# Level 1: Standard Thinking
> think about how to implement caching

# Level 2: Deep Thinking
> think hard about the migration strategy

# Level 3: Maximum Thinking
> ultrathink about the security architecture

# Kombiniert mit Plan Mode:
> ultrathink + plan mode:
> Design a zero-downtime migration from
> PostgreSQL to a distributed database.
> Consider data consistency, rollback strategy,
> and performance during migration.

# Tab Toggle in Claude Code CLI:
# Tab         → Thinking ein/aus
# Shift+Tab   → Plan Mode ein/aus

Wann welchen Modus nutzen?

Die Wahl zwischen Standard-Modus, Think, Plan Mode und Ultrathink hängt von drei Faktoren ab: Komplexität der Aufgabe, Risiko bei Fehlern und Budget. Hier ist ein praktischer Entscheidungsbaum den du im Alltag nutzen kannst. Standard-Modus (kein Keyword): Für einfache, klar definierte Aufgaben mit niedrigem Risiko. Tippfehler fixen, eine Variable umbenennen, einen Kommentar hinzufügen, eine einfache Funktion schreiben. Kostet am wenigsten, ist am schnellsten. 'think': Für mittelkomplexe Aufgaben wo ein bisschen Nachdenken hilft. Eine neue Funktion implementieren, einen Unit Test schreiben, einen bestehenden Bug fixen, eine Datei refactoren. Das ist der Sweet Spot für den Alltag — merkbar bessere Qualität bei geringen Mehrkosten. Plan Mode: Wenn du erst verstehen willst BEVOR du handelst. Neue Codebase erkunden, großes Refactoring planen, Architektur-Entscheidung treffen, Migration vorbereiten. Produziert keinen Code, verhindert aber teure Fehlentscheidungen. 'think hard': Für komplexe Aufgaben mit hohem Risiko. Multi-Datei-Änderungen, API-Design, Datenbankschema-Entwurf, Performance-Optimierung, Security-relevanter Code. Die Investition lohnt sich weil Fehler hier teuer wären. 'ultrathink': Nur für die schwierigsten Aufgaben. System-Architektur von Grund auf, komplexe Algorithmen, kritische Security-Entscheidungen, schwer reproduzierbare Bugs. Kosten-Nutzen muss stimmen — ultrathink bei einem Tippfehler ist Geldverschwendung. Kombinationen: Plan Mode → think hard ist ein mächtiger Workflow. Erst verstehen (Plan), dann gründlich implementieren (think hard). Besonders für große Features empfohlen. Mein Alltags-Workflow: 80% 'think' für den Standard, 15% 'think hard' für wichtige Aufgaben, 4% Plan Mode für Exploration, 1% 'ultrathink' für die wirklich harten Nüsse.

ENTSCHEIDUNGSMATRIX
━━━━━━━━━━━━━━━━━━

STANDARD (kein Thinking):
├── Einfache Code-Änderungen
├── Bekannte Patterns anwenden
├── Kleine Bug Fixes
└── Formatierung / Refactoring

THINK:
├── API-Design Entscheidungen
├── Datenbank-Schema Design
├── Mittlere Architektur-Fragen
└── Code Review

THINK HARD / ULTRATHINK:
├── Komplexe Migrations-Strategien
├── Security-Architektur
├── Performance-kritische Algorithmen
└── System-Design mit vielen Constraints

PLAN MODE:
├── Multi-File Änderungen
├── Neue Features > 50 Zeilen Code
├── Refactoring über mehrere Module
└── Alles wo der User die Richtung bestätigen sollte

ULTRATHINK + PLAN MODE:
├── Architektur-Redesign
├── Neue Microservice-Systeme
├── Zero-Downtime Migrationen
└── Sicherheitskritische Änderungen

Das Revision-Engine Pattern

Das Revision-Engine Pattern kombiniert Extended Thinking mit Self-Critique zu einem leistungsstarken Qualitätssicherungs-Workflow — alles in einem einzigen Prompt. Claude implementiert, reflektiert über die eigene Lösung, findet Schwachstellen, und verbessert sie — automatisch und ohne dass du eingreifen musst. Der Prompt-Aufbau: 'Think hard: Implementiere [Aufgabe]. Nachdem du fertig bist, reviewe deine eigene Implementation als kritischer Senior Developer. Identifiziere 3 Schwachstellen. Fixe alle drei. Zeige mir die finale Version.' Claude durchläuft den gesamten Zyklus in einem Durchgang. Das Besondere an diesem Pattern: Es nutzt Extended Thinking für die interne Qualitätsprüfung. Während Claude den Code reviewt, denkt es in seinem Thinking-Block über subtile Probleme nach die bei einem oberflächlichen Review übersehen würden — Race Conditions, Edge Cases, Memory Leaks, Sicherheitslücken. Das Pattern produziert konsistent höherwertige Ergebnisse als ein einfacher Implementierungs-Prompt. In unseren Tests reduziert es die Anzahl der Bugs im generierten Code um 40-60%, besonders bei komplexer Logik und Error Handling. Variationen: Du kannst die Anzahl der Iterationen erhöhen ('reviewe und verbessere dreimal'), spezifische Review-Kriterien vorgeben ('reviewe besonders auf Thread-Safety und Memory-Management'), oder verschiedene Perspektiven anfordern ('reviewe als Security-Experte und als Performance-Engineer'). Der Kostenaspekt: Das Pattern verbraucht mehr Tokens als ein einfacher Prompt — typischerweise 2-3x so viel. Aber der Qualitätsgewinn rechtfertigt die Kosten bei wichtigem Code. Für kritische Business-Logik, Security-Code und öffentliche APIs ist das Pattern die Investition wert. Ein Praxis-Tipp: Kombiniere das Revision-Engine Pattern mit dem Think-Plan-Execute Pattern. Erst planen, dann mit Revision-Engine implementieren. Die Ergebnisse sind bemerkenswert nahe an dem was ein erfahrener menschlicher Entwickler produzieren würde.

# Mehrere Kritik-Runden für bessere Qualität:

> ultrathink + plan mode:
> Create a deployment strategy for our microservices.
>
> Then critique your plan for:
> - Single points of failure
> - Security vulnerabilities
> - Cost optimization opportunities
> - Rollback scenarios
>
> Fix anything you find and present the final version.

# Ergebnis: Claude denkt tief nach, plant, kritisiert
# sich selbst und liefert eine überarbeitete Version.

# Multi-Perspective Review:
> think hard about this PR from the perspectives of:
> - Senior Backend Engineer (architecture)
> - Security Auditor (vulnerabilities)
> - Performance Engineer (bottlenecks)
> - Junior Developer (readability)

Kosten-Optimierung

Extended Thinking verbessert die Qualität, kostet aber zusätzliche Tokens. Die Kunst liegt darin, die Kosten-Qualitäts-Balance für jede Aufgabe richtig zu treffen — weder zu viel zu investieren bei trivialen Tasks noch zu wenig bei kritischen Entscheidungen. Die größte Kostenersparnis: Das richtige Modell für die Aufgabe wählen. Sonnet mit 'think hard' ist in den meisten Fällen besser UND günstiger als Opus ohne Extended Thinking. Die Kombination aus Modell und Thinking-Level ist der mächtigste Kostenhebel. Regel 1: Standard für 80% der Aufgaben. Die meisten alltäglichen Tasks — kleine Edits, einfache Features, Bug-Fixes — brauchen kein Extended Thinking. Standard-Modus ist schnell und günstig. Regel 2: 'think' als Default für alles Nichttriviale. Wenn du unsicher bist welche Stufe richtig ist, nimm 'think'. Es kostet wenig extra (typischerweise 0.01-0.05 USD) und verbessert die Qualität merkbar. Regel 3: 'think hard' und 'ultrathink' nur gezielt einsetzen. Definiere klare Kriterien: Betrifft die Änderung mehr als 3 Dateien? Ist Security betroffen? Geht es um Architektur? Dann 'think hard'. Ist es ein fundamental neues System-Design? Dann 'ultrathink'. Regel 4: Plan Mode ist günstig. Da Claude im Plan Mode keine Code-Änderungen macht, verbraucht es weniger Action-Tokens. Nutze Plan Mode großzügig für Exploration — die Tokens für einen guten Plan sparen ein Vielfaches an Tokens für fehlgeschlagene Implementierungen. Monitoring: Nutze regelmäßig /cost um deinen Verbrauch zu prüfen. Identifiziere die teuersten Tasks und überlege ob ein günstigeres Thinking-Level gereicht hätte. Über Zeit entwickelst du ein Gefühl für die optimale Balance.

KOSTENOPTIMIERUNG MIT THINKING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STRATEGIE: OpusPlan Pattern
→ 10-20% des Budgets: Opus für Planung
→ 80-90% des Budgets: Sonnet für Implementierung
→ Ergebnis: 60-70% Ersparnis vs. nur Opus

PRAKTISCH:
1. Ultrathink mit Opus für den Plan
2. /model wechseln zu Sonnet
3. Sonnet implementiert den Plan

THINKING TOKENS SIND "UNSICHTBAR":
→ Ein "think hard" Call kann 10x mehr
   Tokens verbrauchen als die finale Antwort
→ Budgetiere für unsichtbare Reasoning-Kosten
→ Nutze /cost um den Verbrauch zu tracken

FAUSTREGEL:
Standard Task  → Kein Thinking → ~$0.01
Mittlerer Task → Think        → ~$0.05
Komplexer Task → Ultrathink   → ~$0.15-0.30

Zusammenfassung

• ✅ Extended Thinking: Dedizierter Denkraum vor der Antwort
• ✅ Budget Tokens: Steuert wie viel Claude "nachdenken" darf
• ✅ Plan Mode: Shift+Tab für Explore → Plan → Execute Workflow
• ✅ Trigger Keywords: think → think hard → ultrathink
• ✅ Kombinieren: ultrathink + plan mode für maximale Qualität
• ✅ Kosten: OpusPlan Pattern — Opus plant, Sonnet implementiert
• ✅ Revision Engine: Implement → Critique → Fix für Iteration