Claude Code effizient nutzen: Kontext, Modelle und Kontrolle

Für die meisten täglichen Änderungen ist das Standardmodell der vernünftige Start. Fable 5 gehört zu schwierigen, mehrdeutigen oder sehr langen Aufgaben, bei denen kleinere Modelle trotz gutem Kontext an eine Grenze stoßen. Mythos 5 ist dagegen kein allgemeiner Produktivitätsmodus für Claude Code, sondern eine nur begrenzt verfügbare Variante für ausgewählte Cybersecurity- und Biologiepartner.

Die wichtigste Regel: Beschreibe nicht nur, was Claude tun soll. Definiere auch, woran Claude selbst und du anschließend erkennen können, dass die Arbeit richtig abgeschlossen ist.

Der effizienteste Arbeitszyklus beginnt vor dem ersten Prompt

Ein guter Auftrag enthält vier Angaben:

• das gewünschte Ergebnis,
• die betroffenen Dateien oder den vermuteten Bereich,
• klare Grenzen,
• einen überprüfbaren Endzustand.

Aus „Behebe den Login-Fehler“ wird zum Beispiel: „Nach einem Session-Timeout bleibt der Bildschirm leer. Untersuche den Refresh-Flow unter src/auth/, schreibe zuerst einen reproduzierenden Test, behebe die Ursache und führe die betroffenen Tests aus. Ändere keine öffentlichen API-Verträge.“

Das ist keine Prompt-Magie. Es ist eine kleine technische Spezifikation. Die offiziellen Best Practices empfehlen genau diese Kombination aus konkretem Kontext und einer Prüfung, die Claude selbst ausführen kann.

1. Erst erkunden, dann die richtige Arbeitstiefe wählen

Claude Code kann Dateien lesen, Befehle ausführen und Änderungen über mehrere Schritte bearbeiten. Deshalb sollte die erste Frage bei unbekanntem Code nicht „Kannst du das ändern?“ lauten, sondern „Welche Dateien, Abhängigkeiten und Tests sind betroffen?“.

Für eine kleine Umbenennung wäre ein eigener Plan nur Reibung. Bei einer Änderung über mehrere Dateien, einer fremden Codebasis oder unsicherem Lösungsweg ist die Reihenfolge erkunden → planen → umsetzen → prüfen sinnvoll. Anthropic beschreibt diesen Ablauf ebenfalls als Schutz davor, das falsche Problem sauber zu lösen.

Praktisch heißt das:

1. Lass Claude die betroffenen Stellen nennen und offene Annahmen markieren.
2. Prüfe den Plan bei mehrteiligen oder riskanten Änderungen.
3. Lass erst danach implementieren.
4. Beende die Aufgabe mit Tests, Build, Lint oder einem anderen sichtbaren Nachweis.

2. Gib nur den Kontext, der die Entscheidung verändert

Mehr Kontext ist nicht automatisch besser. Jede Nachricht, gelesene Datei und Befehlsausgabe füllt das Kontextfenster. Mit wachsender Sitzung können alte Fehlversuche und irrelevante Ausgaben die Arbeit erschweren. Die Nutzungs- und Kontextanleitung nennt deshalb zwei einfache Werkzeuge: /clear zwischen unabhängigen Aufgaben und /compact während einer langen, zusammenhängenden Aufgabe.

Für Dateien gilt dasselbe. Verweise auf einen Pfad, statt eine große Datei vollständig in den Prompt zu kopieren. Claude kann dann gezielt lesen. Ein enger Startpunkt spart Kontext und macht leichter sichtbar, ob der Agent in die falsche Richtung sucht.

3. Behandle CLAUDE.md wie knappen Produktionscode

CLAUDE.md ist das dauerhafte Onboarding-Dokument für ein Repository. Es sollte nicht alles erklären, sondern nur das enthalten, was Claude nicht zuverlässig aus dem Code ableiten kann:

• ungewöhnliche Build- und Testbefehle,
• abweichende Architektur- oder Stilregeln,
• Repository-Etikette,
• kritische Grenzen und bekannte Fallstricke.

Mit /init lässt sich eine Ausgangsversion erzeugen. Danach muss sie gepflegt und gekürzt werden. Die Dokumentation zu großen Codebasen empfiehlt schlanke, geschichtete Dateien: allgemeine Regeln an der Wurzel, lokale Hinweise im passenden Unterverzeichnis. Wiederverwendbare Spezialabläufe gehören eher in Skills; zwingende, deterministische Prüfungen eher in Hooks.

Eine gute Löschfrage lautet: „Würde Claude ohne diese Zeile einen realen Fehler machen?“ Wenn nicht, belastet die Zeile jede Sitzung ohne sicheren Nutzen.

Modell und Aufwand nach dem Problem wählen

Das größte Modell für jede Aufgabe zu verwenden ist weder automatisch schneller noch wirtschaftlicher. Die aktuelle Modellkonfiguration trennt Modellfähigkeit und Aufwand. Das Modell bestimmt grob, welche Probleme Claude lösen kann; der Effort-Level beeinflusst, wie gründlich es liest, Werkzeuge nutzt und prüft.

Die folgende Matrix ist eine redaktionelle Entscheidungshilfe. Sie ersetzt keinen Test mit dem eigenen Repository.

Fable 5 und Mythos 5 richtig einordnen

Stand 6. August 2026 ist Fable 5 in Claude Code über /model fable auswählbar, sofern Konto, Organisation, Anbieter und installierte Claude-Code-Version den Zugriff erlauben. Es ist kein Standardmodell. Anthropic positioniert es für besonders schwierige und lange Aufgaben. Der Leitfaden zu Modell und Effort empfiehlt einen größeren Modellwechsel erst dann, wenn Kontext, Werkzeuge und Aufgabenrahmen stimmen, das kleinere Modell das Problem aber trotzdem nicht lösen kann.

Das ist eine nützliche Diagnose:

• Zu wenig Wissen oder Fähigkeit: größeres Modell erwägen.
• Zu wenig Sorgfalt: Effort erhöhen oder die Prüfung expliziter machen.
• Zu wenig Kontext: zuerst Dateien, Regeln oder Dokumentation gezielt bereitstellen.
• Zu große Aufgabe: Arbeitsfläche teilen, bevor das Modell gewechselt wird.

Fable und Mythos basieren laut Anthropics Ankündigung auf demselben Grundmodell. Fable enthält zusätzliche Schutzmechanismen für sensible Cybersecurity- und Biologieanfragen. Mythos 5 lockert solche Schutzmechanismen für einen kleinen Kreis geprüfter Partner. Die Mythos-Produktseite nennt eine eingeschränkte Verfügbarkeit und besondere Aufbewahrungsbedingungen.

Für normale Softwareentwicklung folgt daraus: Mythos ist kein „noch schnelleres Fable“ und keine Option, die ein Team zur Produktivitätssteigerung standardmäßig aktivieren sollte. Wer überhaupt Zugang benötigt, braucht einen begründeten Dual-Use-Anwendungsfall, eine formale Freigabe und strengere Kontrollen.

Für eine vertiefte Einordnung des automatischen Sicherheits-Fallbacks passt die Saaspective-Analyse Claude Fable 5: Was der Sicherheits-Fallback für Unternehmen bedeutet.

Prüfbarkeit schlägt Promptkunst

Claude kann nur so lange selbstständig korrigieren, wie es ein maschinenlesbares Signal gibt. Das kann ein Test, ein Build-Exitcode, ein Linter, ein Vergleich mit einer Fixture oder ein Screenshot sein. Ohne ein solches Signal endet die Schleife bei „sieht fertig aus“.

Ein effizienter Auftrag nennt deshalb den Nachweis gleich mit:

• Ein Bugfix braucht einen Test, der vor der Korrektur fehlschlägt und danach besteht.
• Ein Refactoring braucht identisches Verhalten plus passende Tests.
• Eine UI-Änderung braucht einen visuellen Vergleich.
• Eine Migration braucht Build, Tests und einen dokumentierten Rückweg.
• Eine Konfigurationsänderung braucht eine begrenzte Smoke-Prüfung.

Bei riskanten Änderungen sollte die letzte Kontrolle nicht aus derselben Sitzung stammen. Der interne Guide Code zuerst prüfen zeigt eine kurze Reihenfolge von Zweck, Diff, automatischen Checks, Verhalten, Sicherheit und Rückweg.

Solo-Nutzer und Unternehmen brauchen denselben Loop, aber andere Grenzen

Für einzelne Entwickler

Ein guter Standard ist ein Repository, ein Branch und eine Aufgabe pro Sitzung. Starte mit dem Standardmodell, gib Akzeptanzkriterien vor und lasse die engsten relevanten Tests laufen. Nutze /clear, sobald du zu einem anderen Problem wechselst. Fable lohnt sich erst, wenn ein sauber begrenztes Problem für das Standardmodell tatsächlich zu schwer oder zu lang ist.

Auch bei privaten Projekten gehören Secrets, produktive Zugangsdaten und unkontrollierte Deployments nicht in den normalen Arbeitsraum des Agenten.

Für kleine und große Teams

Teams müssen aus persönlichen Gewohnheiten eine wiederholbare Betriebsweise machen:

• Ein Verantwortlicher pflegt die gemeinsame Claude-Code-Konfiguration.
• Verbindliche Checks laufen als CI oder Hooks, nicht nur als Textwunsch.
• Berechtigungen begrenzen Dateien, Werkzeuge und Domains.
• Sandbox und Berechtigungsregeln werden gemeinsam genutzt.
• Kritische Änderungen benötigen unabhängiges Review.
• Modellzugriff und maximale Effort-Level werden nach Rolle oder Aufgabe begrenzt.

Die Berechtigungsdokumentation beschreibt Permissions und Betriebssystem-Sandbox als ergänzende Ebenen. Der gemeinsame BSI/ANSSI-Leitfaden zu AI Coding Assistants ordnet unsicheren Code, Datenabfluss und Anbieterabhängigkeit als technische und organisatorische Risiken ein. Das spricht nicht gegen Claude Code. Es spricht für eine kleine, kontrollierbare Arbeitsfläche.

Vor einem breiteren Einkauf hilft zusätzlich der Guide KI-SaaS sicher auswählen bei Vertrag, Datenfluss, Pilot und Exit.

Produktivität an akzeptierten Änderungen messen

Aktivität ist leicht zu zählen, Nutzen nicht. Claude Code kann per OpenTelemetry unter anderem Sitzungen, Token, geschätzte Kosten, Commits und Pull Requests exportieren. Die Kostendaten sind laut Dokumentation Näherungen. Vor allem beweisen mehr Commits oder Codezeilen noch keine bessere Lieferung.

Für einen Solo-Nutzer reichen vier Werte:

• Zeit bis zum bestandenen Check,
• eigene aktive Nacharbeit,
• Zahl der Rücksprünge oder Neuansätze,
• Verbrauch beziehungsweise Kosten pro akzeptierter Aufgabe.

Für Teams kommen hinzu:

• Zeit bis zum akzeptierten Pull Request,
• Review-Dauer und Korrekturschleifen,
• nachträgliche Fehler und Rollbacks,
• unerwartete Datei- oder Berechtigungsänderungen.

Die Forschung erlaubt keine allgemeine Beschleunigungsgarantie. Der DORA-Bericht 2025 beschreibt AI vor allem als Verstärker vorhandener Organisationsstärken und -schwächen. METR weist in seinem Update vom Februar 2026 darauf hin, dass neuere Messungen wegen Auswahl- und Beobachtungseffekten keinen verlässlichen aktuellen Universalwert liefern.

Der faire Vergleich lautet deshalb nicht „mit oder ohne AI“ im Allgemeinen. Vergleiche ähnliche Aufgaben im eigenen Prozess und entscheide anhand akzeptierter Ergebnisse.

Fünf typische Effizienzfallen

Alles in einer Sitzung erledigen

Eine Sitzung, die Bugfix, Migration und Dokumentation mischt, trägt den alten Kontext in jeden neuen Schritt. Besser: pro unabhängiger Aufgabe /clear oder eine neue Sitzung.

Fable als Dauereinstellung verwenden

Fable kann bei anspruchsvollen Langläufern sinnvoll sein. Bei klaren Routinearbeiten bezahlt man jedoch für Fähigkeit, die nicht gebraucht wird, und verbraucht mehr Kontingent. Erst das Problem klassifizieren, dann eskalieren.

Eine lange CLAUDE.md mit Qualität verwechseln

Viele Regeln konkurrieren um Aufmerksamkeit und veralten. Kurze, testbare Anweisungen plus deterministische Hooks sind zuverlässiger als ein Handbuch im Kontextfenster.

Grüne Tests mit vollständiger Richtigkeit verwechseln

Ein Test kann die falsche Sache prüfen. Kritische Logik braucht Diff-Review, passende Negativfälle und gegebenenfalls eine unabhängige Security-Prüfung.

Den Agenten mit unklaren Zielen starten lassen

Autonomie vergrößert einen schlechten Auftrag. Wenn das gewünschte Verhalten, die Grenzen oder der Nachweis fehlen, sollte Claude zuerst Fragen stellen oder einen Plan erstellen.

Ein sinnvoller Start für die nächste Sitzung

1. Wähle eine kleine, nicht kritische Aufgabe.
2. Schreibe Ergebnis, Grenzen und Nachweis in vier bis sechs Sätzen.
3. Starte mit dem Standardmodell und Standard-Effort.
4. Lass Claude erst die betroffenen Stellen nennen.
5. Nutze Plan Mode nur, wenn mehrere Dateien, Unsicherheit oder hohes Risiko es rechtfertigen.
6. Lass Claude den passenden Check ausführen und das Ergebnis zeigen.
7. Prüfe den Diff selbst.
8. Notiere Zeit, Nacharbeit und Verbrauch.
9. Eskaliere Modell oder Effort nur mit einer klaren Diagnose.

Claude Code ist am effizientesten, wenn der Arbeitsraum klein, der Kontext relevant und das Ende messbar ist. Das stärkste Modell kann fehlende Akzeptanzkriterien, schwache Tests oder unklare Zuständigkeit nicht ersetzen.