Modell und Aufwand in Claude Code: Mehr Wissen vs. mehr Anstrengung

Claude Code bietet dir zwei Einstellungen, die beide die Antwort scheinbar „verbessern“: das Modell und den Aufwand. Aber was bewirken diese tatsächlich im Output? Und wie weißt du, ob du ein anderes Modell wählen oder einfach nur den Aufwand ändern solltest?

Es ist leicht anzunehmen, dass ein größeres Modell wie Fable einen intelligenteren Output liefert als Sonnet und dass ein höherer Aufwand einfach bedeutet, dass Claude länger nachdenkt, bevor es antwortet.

Die erste Annahme stimmt. Unsere größten Modelle sind leistungsfähiger, gemessen an branchenüblichen Benchmarks.

Aber Aufwand bedeutet mehr als „Denkzeit“. Der Aufwand steuert, wie viel Arbeit Claude insgesamt für deine Anfrage leistet. Dazu gehört, wie lange es denkt, aber auch:

• wie viele Dateien es liest;
• wie viel es verifiziert; und
• wie weit es eine mehrstufige Aufgabe durchführt, bevor es sich bei dir meldet.

Bei höherem Aufwand unternimmt Claude mehr dieser Aktionen (Dateien lesen, Tests ausführen, doppelt prüfen), bevor es zu dir zurückkommt. Bei geringerem Aufwand fragt es lieber nach mehr Kontext, als Tokens dafür auszugeben, etwas selbst herauszufinden.

Wie die Modellauswahl funktioniert

Um zu verstehen, was die Modelleinstellung tatsächlich steuert, hilft es, ganz am Anfang zu beginnen, in dem Moment, in dem du die Eingabetaste drückst.

Claude Code setzt deine Nachricht zusammen mit dem System-Prompt, den Tool-Definitionen, deiner CLAUDE.md, dem Gesprächsverlauf und allen Dateien im Kontext. All dies wird als eine einzige Anfrage an die API gesendet.

Alles, was Claude Code hat, wird in eine einzige API-Anfrage verpackt. Auf dem Server wird der Text tokenisiert, bevor er das Modell überhaupt erreicht.

Das Modell sieht all dies jedoch nie als Klartext. Das erste, was auf dem Server passiert, ist die Tokenisierung: Der Text wird in Stücke aufgeteilt, und jedes Stück wird einer ganzen Zahl aus einem festen Vokabular zugeordnet, mit dem das Modell trainiert wurde. const könnte auf 1978 abgebildet werden, await auf 4293. Ab hier ist dein Prompt ein Array von Ganzzahlen.

Der Tokenizer zerlegt deinen Text in Stücke und ordnet jedes Stück einer ganzen Zahl in einem festen Vokabular zu. Jeder Block in der oberen Zeile wird zu seiner Token-ID (untere Zeile); die gezeigten IDs sind illustrativ.

Die Aufgabe des Modells ist es, dieses Array zu nehmen und den nächsten Token vorherzusagen. Es tut dies, indem es eine Wahrscheinlichkeit für jeden Token in seinem Vokabular berechnet und aus den höchsten auswählt. Nach „const x = await“ setzt ein gut trainiertes Modell eine hohe Wahrscheinlichkeit auf „fetch“ (sehr wahrscheinlich) und nahe Null auf „banana“ (überhaupt nicht wahrscheinlich).

Die Vorhersage des Modells ist eine Wahrscheinlichkeit für jeden Token in seinem Vokabular. Der Abstand zwischen dem besten Tipp und einem nicht verwandten ist enorm.

Was deine Eingabe-Tokens in diese Wahrscheinlichkeiten verwandelt, sind die Gewichte (auch Parameter genannt): Milliarden von Zahlen, die in großen Matrizen angeordnet sind. Um einen Token vorherzusagen, durchläuft das Modell deine Eingabe durch diese Matrizen (eine lange Kette von Matrixmultiplikationen) und liest die Wahrscheinlichkeiten am Ende ab. Die Gewichte sind der Ort, an dem alles lebt, was das Modell „weiß“.

Die Gewichte jedes Modells werden während des Trainings festgelegt, und wenn du Anfragen sendest, sind sie schreibgeschützt. Nichts in deinem Prompt, deiner CLAUDE.md oder deinem Kontext ändert sie. Falls du schon einmal auf das Wort Inference gestoßen bist, bedeutet das genau das: Das Modell nach dem Training verwenden, mit festen Gewichten.

Dein Prompt geht hinein, Wahrscheinlichkeiten kommen heraus. Die Gewichte in der Mitte ändern sich nicht.

Alles, was Claude über TypeScript, gängige Frameworks oder andere allgemeine Programmierkenntnisse weiß, wurde während des Trainings in diese Gewichte kodiert.

Dein Prompt und dein Kontext können die Vorhersage dennoch lenken. Deinen echten Code vor Claude zu platzieren ist eine Lenkung, und das funktioniert sehr gut. Dies fügt den Gewichten selbst jedoch nichts hinzu.

Wenn eine Bibliothek zum Zeitpunkt des Trainings des Modells nicht existierte, ist sie nicht in den Gewichten. Du kannst die Dokumentation in den Kontext legen, und Claude wird sie verwenden, aber das ist Lenkung, kein Lernen. Claudes Antwort wird nur für diese eine Anfrage beeinflusst, aber das zugrunde liegende Modell hat nichts behalten.

Wenn Claude selbstbewusst eine API aufruft, die nicht existiert (eine Halluzination), dann produzieren die Gewichte eine Token-Sequenz, die aus den Trainingsmustern plausibel erscheint, kein fehlgeschlagener Lookup.

Was bewirkt also das Ändern des Modells? Es tauscht aus, welcher Satz von eingefrorenen Gewichten deine Anfrage bearbeitet.

Das Modell generiert nicht eine ganze Antwort auf einmal. Es sagt einen Token voraus, hängt ihn an die Sequenz an und führt die gesamte Berechnung erneut durch, um den nächsten zu erhalten. Eine Antwort mit 200 Tokens bedeutet 200 separate Durchläufe durch die Gewichte. Diese Schleife verursacht den Großteil deiner Wartezeit (und deiner Output-Kosten).

Die Sequenz wächst um genau einen Token pro Schritt. Das Modell liest jedes Mal das gesamte Array erneut, um vorherzusagen, was als Nächstes kommt.

Die Modelleinstellung entscheidet, welche Gewichte deine Anfrage bearbeiten, und sie entscheidet auch, was jeder Output-Token kostet.

Was sie nicht entscheidet, ist wie viele Tokens generiert werden. Diese Anzahl kann beim gleichen Prompt stark variieren, je nachdem, wie viel Arbeit Claude zu leisten beschließt.

Und genau das steuert der Aufwand.

Wie der Aufwand funktioniert

Während Claude Code an einer Aufgabe arbeitet, fallen die Tokens, die es generiert, in einige Kategorien:

• Thinking: Die Überlegungen, die du vor und zwischen Aktionen streamen siehst.
• Tool-Aufrufe: Strukturierte Blöcke, die ein Tool wie „Read“ oder „Edit“ und dessen Argumente benennen, die Claude Code dann parst und ausführt.
• Text an dich: Der Plan, Fortschrittsaktualisierungen, die Zusammenfassung am Ende.

All dies sind gewöhnliche Output-Tokens aus derselben Schleife, die zum gleichen Satz abgerechnet werden. Thinking-Tokens zum Beispiel werden genau wie die anderen Output-Tokens generiert und bleiben für den Rest dieser Runde im Kontext.

Wenn Claude dazu übergeht, Code zu schreiben, sind seine früheren Überlegungen Teil der Eingabe, genau wie eine Datei, die es gelesen hat.

Der gesamte Output von Claude besteht aus Tokens. Thinking, Tool-Aufrufe und Text an dich werden alle aus derselben Schleife generiert.

Wie ändert der Aufwand dies also? Die Aufwandsstufe wird als Teil der Anfrage an das Modell gesendet, direkt neben deinem Prompt. Das Modell wurde darauf trainiert zu verstehen, wie es sich bei jeder Aufwandsstufe zu verhalten hat, und dieses gelernte Verhalten ist in den eingefrorenen Gewichten verankert.

Wenn deine Anfrage eintrifft, ist der Aufwand nur eine weitere Eingabe, auf die das Modell reagiert, genauso wie es auf deinen Prompt-Text reagiert. Es legt fest, wie gründlich und wie sicher Claude sein muss, bevor es die Aufgabe als erledigt betrachtet. Dies wird bei jeder Runde abgewogen, und eine höhere Sicherheit erfordert mehr Tokens, um sie zu erreichen.

Gleicher Prompt, zwei Aufwandsstufen. Der Pfad mit hohem Aufwand generiert ungefähr 7-mal mehr Tokens, um eine Antwort mit höherer Sicherheit zu erreichen.

Bei höheren Aufwandsstufen beginnt Claude oft damit, einen Plan zu erstellen, und die Aufwandsstufe beeinflusst die Tiefe und Breite dieses Plans. Aber der Plan ist nicht in Stein gemeißelt. Wenn Claude Ergebnisse von seinen Aktionen zurückbekommt, aktualisiert es sein Bild davon, wie weit es fortgeschritten ist und wie sicher es sich des bisherigen Ergebnisses ist.

Wenn Schritt 1 eines Drei-Hypothesen-Debugging-Plans den Fehler findet, sind „Hypothesen 2 und 3 untersuchen“ möglicherweise nicht mehr nötig. Claude wird dies normalerweise explizit sagen (z. B. „die erste Überprüfung hat ihn gefunden, also sind die restlichen Überprüfungen nicht nötig“) und vorausspringen. Du siehst das in Claude Code passieren, wenn Aufgabenlisten während der Ausführung überarbeitet werden.

Ein höherer Aufwand macht es wahrscheinlicher, dass Claude doppelt prüft, z. B. die gefundene Antwort verifiziert oder doch noch die Hypothesen untersucht, die es hätte überspringen können. Im Allgemeinen wird es die Nutzung bei einer einfachen Aufgabe jedoch nicht künstlich aufblähen, nur weil die Aufwandsstufe hochgedreht ist. „Overthinking“ ist etwas, auf das unser Team während des Modelltrainings speziell achtet, da es die Effektivität beeinträchtigt.

Eine Aufwandsstufe auswählen

Für die meisten Aufgaben verwende die Standard-Aufwandsstufe des Modells. Die Standardstufe ist die Stufe, bei der Claude seinen Token-Verbrauch auf das skaliert, was die meisten Leute für eine Aufgabe ausgeben möchten.

Betrachte den Aufwand als manuelle Übersteuerung, wie hart und wie lange Claude arbeitet. Greife bewusst darauf zurück, wenn du eine starke Präferenz für Gründlichkeit oder Geschwindigkeit hast, basierend auf deinem Fachgebiet oder der Art deiner Arbeit, und behandle es als allgemeine Präferenz, nicht als Entscheidung von Aufgabe zu Aufgabe.

Ein praktischer Hinweis nach dem Start von Opus 4.8: In unseren Tests liefert die Standard-Aufwandsstufe bei Opus 4.8 bessere Ergebnisse bei etwa der gleichen Anzahl von Tokens wie die Standard-Aufwandsstufe bei Opus 4.7 für dieselbe Aufgabe.

Was ändern, wenn Claude etwas falsch macht?

Wenn Claude etwas falsch macht, sollte dein erster Instinkt nicht sein, eine Einstellung zu ändern. Du solltest dir den Kontext ansehen, den du ihm gegeben hast. Ist dein Prompt zu vage? Ist Claude mit den richtigen Tools verbunden? Hat es die richtigen Fähigkeiten?

Wenn du den Aufwand für eine Aufgabe erhöhst, die ihn nicht benötigen sollte, liegt die Lösung normalerweise vorgelagert: in deinem Kontext, deiner CLAUDE.md oder wie die Aufgabe abgegrenzt ist.

Aber nehmen wir an, du hast klaren Kontext gegeben und Claude macht es trotzdem falsch. Die Frage, die du dir stellen musst, ist: Hat es nicht ______ genug versucht, oder wusste es nicht genug?

Modell: Das Problem war zu schwer

Wähle ein größeres Modell, wenn das Problem wirklich schwer ist, wie subtile Fehler, unbekannte Fachgebiete, Architekturentscheidungen. Ein größeres Modell ist das, was du willst, wenn das kleinere Modell selbstbewusst falsch liegt, egal wie viel Kontext du ihm gibst.

Größere Modelle sind auch besser darin, mit Mehrdeutigkeiten umzugehen. Bei kleineren Modellen sind spezifische Anweisungen, die die Ausführung lenken, ein besseres Rezept für Erfolg.

Wähle ein kleineres Modell, wenn die Arbeit Routine ist: Änderungen, die du präzise beschreiben kannst, mechanische Änderungen, Fragen zu Code, der bereits im Kontext ist. Es gibt keinen Grund, für Fähigkeiten zu bezahlen, die die Aufgabe nicht benötigt.

Wenn Claude den gesamten relevanten Kontext hatte, es klar versucht hat und es trotzdem falsch gemacht hat, ist das ein Signal, ein größeres Modell zu wählen. Und wenn du das größere Modell verwendest und die Arbeit schon eine Weile Routine war, führt ein Wechsel nach unten zu mehr Geschwindigkeit und in der Regel zu geringeren Kosten, ohne die Output-Qualität zu beeinträchtigen.

Aufwand: Claude hat sich nicht genug angestrengt

Wähle eine höhere Aufwandsstufe, wenn Claude es falsch gemacht hat, weil es sich nicht genug angestrengt hat: eine Datei übersprungen, die Tests nicht ausgeführt oder seine Arbeit nicht doppelt überprüft. Dies ist am relevantesten, wenn du eine Aufwandsstufe unterhalb der Standardeinstellung des Modells gewählt hast.

Der Spezialist, der Experte und der Generalist

Eine Art, wie ich über die beiden Einstellungen gerne denke, ist, dass Fable ein Spezialist ist, der Probleme bewältigen kann, die fast niemand sonst hat, Opus der Experte ist und Sonnet ein wirklich guter Generalist. Die Aufwandsstufe entscheidet, wie viel Zeit jeder von ihnen mit deiner Aufgabe verbringt.

Opus bei niedrigem Aufwand ist wie fünf Minuten mit einem Experten, der tiefgehende Erfahrung mit Problemen wie deinem hat. Sie bringen Wissen mit, das nirgendwo in deiner Codebasis ist; Muster, die sie schon gesehen haben, Fallstricke, die sie zu überprüfen wissen, die Art von Erfahrung, die du nur bekommst, wenn du viele ähnliche Probleme gelöst hast. Aber fünf Minuten bedeuten ein schnelles Durchlesen deines Codes, nicht einen sorgfältigen Durchgang durch jede Datei.

Sonnet bei hohem Aufwand ist der Generalist mit dem ganzen Nachmittag. Sie sind großartig im Programmieren, und sie werden alles lesen, Dinge ausführen, ihre Arbeit doppelt überprüfen und letztendlich deinen spezifischen Code gründlich verstehen.

Fable ist der Spezialist, den du rufst, wenn alle anderen nicht weiterkommen. Selbst bei niedrigem Aufwand werden sie die Sache erkennen, die sonst niemand bemerken würde. Diese Erkennungsfähigkeit ist auch das, wofür du am meisten bezahlst, also lohnt es sich, sie für die Aufgaben aufzuheben, die sie brauchen.

Keiner davon ist universell „besser“. Die Modelleinstellung ist ungefähr wie leistungsfähig; die Aufwandsstufe ist ungefähr wie gründlich. Die meisten realen Aufgaben brauchen etwas von beidem.

Aufwand, Modell und Token-Verbrauch

Wie interagieren also Modellauswahl, Aufwand und Token-Verbrauch miteinander? Das hängt von der Aufgabe ab.

Bei Routinearbeit mit derselben Aufwandsstufe werden sowohl das größere als auch das kleinere Modell im Allgemeinen richtig liegen. Das größere Modell verbraucht mehr Tokens durch zusätzliche Verifizierungsschritte, zu einem höheren Preis pro Token. Deshalb spart ein Wechsel zum kleineren Modell für Routineaufgaben echtes Geld ohne Qualitätseinbußen.

Kurven dienen nur der Veranschaulichung, gezeigt für eine einzelne Aufgabe, die einfach genug ist, um von beiden Modellen schnell erledigt zu werden. Sie repräsentieren keine realen Benchmark-Daten.

Bei schwierigeren, mehrstufigen Arbeiten dreht sich die Gleichung um. Das kleinere Modell muss sich an die Grenzen seiner Fähigkeiten heranarbeiten und dabei Iterationen verbrauchen, während das größere Modell die gleiche Qualitätsstufe in weniger Schritten erreicht.

Du zahlst mehr pro Token für das größere Modell, aber bei Aufgaben, die das kleinere wirklich fordern, können die Gesamtkosten pro Aufgabe niedriger ausfallen. Und was noch wichtiger ist: Das größere Modell kann Aufgaben abschließen, die das kleinere nicht kann, selbst bei den höchsten Aufwandseinstellungen.

Dies ist am deutlichsten bei Fable. Bei langen, mehrstufigen Arbeiten liegt es am weitesten vorn. In unseren Tests hat es Jobs abgeschlossen, die Opus und Sonnet bei keiner Aufwandsstufe erreichen können. Es kostet auch am meisten pro Token, was der andere Grund ist, es für die Arbeit aufzuheben, die es wirklich braucht.

Kurven dienen nur der Veranschaulichung, gezeigt für eine einzelne Aufgabe, die schwer genug ist, um beide Modelle zu fordern. Sie repräsentieren keine realen Benchmark-Daten.

Der entscheidende Punkt in den obigen Grafiken: Der Aufwand bestimmt, wie weit Claude bereit ist, entlang der Kurve zu reisen. Das bedeutet nicht, dass Claude so weit gehen muss, um die Aufgabe abzuschließen.

Schließlich prägt der Aufwand den Token-Verbrauch, aber er begrenzt ihn nicht. Die einzige harte Grenze im System ist max_tokens, die eine Antwort mitten im Strom abschneidet, wenn sie erreicht wird, aber es ist ein stumpfes Instrument und hauptsächlich für API-Entwickler relevant. Weichere Steuerungen wie Aufgabenbudgets oder die Aufforderung an Claude, es in deinem Prompt kurz zu halten, sind hilfreicher. Sie sind Richtlinien, denen das Modell zu folgen trainiert wurde (es wird versuchen, die Sache abzuschließen, wenn es sich der Grenze nähert), und keine Wand, gegen die es stößt.

Der Aufwand ändert, wie viel Arbeit Claude leistet. Das Modell ändert, was Claude weiß.

Wenn du mit einem Ergebnis unzufrieden bist, überprüfe den Kontext, bevor du eine der beiden Einstellungen anfasst: Gib Claude einen klaren Prompt, die richtigen Tools und Fähigkeiten und eine Möglichkeit, seine eigene Arbeit zu überprüfen.

Wenn Claude es immer noch falsch macht, frage dich: Hat es nicht genug gewusst oder hat es sich nicht genug angestrengt? Nicht genug zu wissen ist ein Modellproblem, sich nicht genug anzustrengen ist ein Aufwandsproblem.

Dieser Artikel wurde geschrieben von @lydiahallie, technische Mitarbeiterin im Claude Code-Team.