Claude Code arbeitet standardmäßig mit mittlerem Aufwand. Max-Einstellung rettet Sie nicht.
Große Coding-Session. 60 Nachrichten. Dreimal habe ich /effort max aktiviert, dreimal wieder deaktiviert. Ergebnis: "partially_achieved." Drei Runden à 25 Minuten, in denen ich Claude dabei zusah, wie es sich im Kreis drehte, während meine eigentliche Aufgabe unberührt blieb.
Dabei habe ich alles richtig gemacht. Claude Code empfiehlt bei der Installation /effort medium, ich denke nicht mal darüber nach und stelle sofort auf high. Weil ich eh nicht alle meine Token verbrauchen kann, und weil Boris Cherny (der Typ, der Claude Code entwickelt hat) gesagt hat, man solle immer die leistungsstärkste Einstellung verwenden.
Hat nichts gebracht. Denn das Problem war nie die Effort-Stufe. Es war das, was ich dem System vorgesetzt habe. Und darüber redet niemand. Die Influencer gratulieren sich lieber gegenseitig dazu, die richtige Slider-Position gefunden zu haben.
TLDR: /effort max kompensiert keinen schlechten Kontext. Meine Daten aus 25 Effort-Befehlen bestätigen das. Die Sessions, die komplexe Aufgaben auf Anhieb lösen, haben alle dasselbe Eröffnungsmuster: einen strukturierten Plan vor dem ersten Tastendruck. Ja, ändere deine Standardeinstellung von medium auf high. Aber wenn das alles ist, was du änderst, wirst du mehr Token dafür ausgeben, durch dieselben Fehler zu loopen. Die richtige Reihenfolge: erst strukturierter Plan, dann max effort. In dieser Reihenfolge.
Was Boris Cherny vor uns allen verstanden hat, und was meine eigenen Session-Daten nach einer Woche des Trackings bestätigt haben: Der Slider ist das Letzte, was du anfassen solltest. Nicht das Erste.
Die Session, die mich am Slider zweifeln ließ
Session 271c43dd. Ich erinnere mich daran, weil /insights sie später als eine meiner längsten markiert hat.
60 Nachrichten. Dreimal bin ich während derselben Session auf /effort max eskaliert, in der Hoffnung, einen Cover-Image-Bug mit roher Gewalt zu lösen, der eigentlich straightforward hätte sein sollen. Claude vertiefte sich in iCloud-Sync-Probleme. Dann schwenkte es zu fnm-Path-Konflikten. Dann tauchte es in node_modules-Auflösung ab. Zwölf Stunden Kontext, und das Modell dachte immer intensiver über die falschen Dinge nach.
Die Cover wurden nie repariert.
Es ist wie gegen einen Boss in einem RPG zu kämpfen, bei dem du immer wieder denselben maximal aufgepowerten Zauber verwendest, und der Boss heilt sich einfach. Irgendwann musst du aufhören und den verdammten Bestiary-Eintrag lesen. Der Zauber war nie das Problem. Du hast die falsche Schwachstelle attackiert.
Ich hatte nicht die falsche Einstellung. Ich war im falschen Korridor.
Diese Erkenntnis sitzt schief, weil sie bedeutet, dass das Ding, das alle optimieren (der Slider), die letzte Variable ist, die zählt, nicht die erste.
Max effort im falschen Korridor bedeutet nur schneller paddeln.
Bevor du herausfindest, was das tatsächlich repariert, musst du verstehen, was der Slider eigentlich tun soll, und warum selbst sein Schöpfer dabei nicht stehen bleibt.
Der Schöpfer von Claude Code läuft auf Max. Aber das ist nicht sein eigentlicher Move.
Boris Cherny ist für mich so etwas wie ein Halbgott. Halb Mensch, halb Daemon-Prozess, der nie aufhört zu shippen.
Der Mann shippt 20 bis 30 Pull Requests jeden Tag. Keine einzige Zeile seit November von Hand editiert. Opus 4.6, extended thinking, maximum effort, immer an. Vor Anthropic hat er 7 Jahre bei Meta verbracht und Code-Qualität für Facebook, Instagram, WhatsApp und Messenger geleitet. Er hat Claude Code allein im September 2024 entwickelt, angefangen mit einem Terminal-Chatbot, der ihm sagen konnte, welche Musik er gerade hörte. Das Ganze war, nach seinen eigenen Worten, ein Versehen.
Seine Begründung dafür, immer das teuerste Modell zu verwenden, ist kontraintuitiv: Es ist tatsächlich billiger. Sonnet braucht drei Iterationen, um zum richtigen Ergebnis zu kommen. Opus braucht eine. Die Gesamtkosten für Opus sind am Ende niedriger trotz des höheren Preises pro Token, weil du aufhörst, für Korrekturschleifen zu zahlen. Die meisten Leute schauen auf den Preis pro Token und nehmen das billigere Modell. Boris schaut auf die Gesamtkosten pro abgeschlossener Aufgabe und nimmt das klügere.
Aber das ist der Teil, den alle bereits aus seinen Interviews zitieren. Den Teil, den sie überspringen, ist das, was vor all dem passiert.
Boris startet etwa 80% seiner Sessions im Plan-Modus. Und Plan-Modus ist kein ausgeklügeltes Orchestrierungssystem. Er hat es selbst beschrieben: Alles was es tut, ist einen Satz in den Prompt einzufügen, der sagt "please don't write any code yet." Das ist das Ganze. Er hat das Feature an einem Sonntagabend in 30 Minuten programmiert, nachdem er GitHub Issues gelesen hatte, wo User das bereits natürlich in ihren Prompts machten. Montagmorgen deployed.
Das zugrundeliegende Prinzip: Wenn der Plan gut ist, ist der Code gut. Seine Worte, nicht meine. Und es ist wahrscheinlich das Wichtigste, was er über Claude Code gesagt hat, was niemand tatsächlich zu verinnerlichen scheint. Das Modell, die Effort-Stufe, das extended thinking, all das kommt nach dem Plan. Immer nach.
Er hat sogar gesagt, der Plan-Modus hat wahrscheinlich eine begrenzte Lebensdauer. Vielleicht einen Monat. Weil das Modell irgendwann von selbst herausfinden wird, wann es planen soll. Aber gerade jetzt, in diesem Zeitfenster, ist es der Job des Menschen, den Plan richtig hinzubekommen. Die Vorarbeit, bevor du anfängst zu kochen. Alles andere folgt daraus.
(Erwähnenswert: Boris arbeitet bei Anthropic mit privilegiertem Zugang zum Modell. Er shippt mit einer Geschwindigkeit, die die meisten von uns nicht erreichen werden, und sein Workflow ist für High-Velocity-Delivery von 20-30 PRs pro Tag optimiert. Das Muster überträgt sich auf deine Projekte. Die exakten Zahlen wahrscheinlich nicht.)
Boris macht max effort. Aber er macht Plan-Modus zuerst.
21 von 25: Was meine Effort-Befehle tatsächlich zeigen
Erst die nackten Zahlen.
/insights hat meine letzten 25 Effort-Befehle seit dem 16. März auditiert. 21 Mal habe ich /effort max verwendet. Einmal /effort medium. Einmal /effort high. Zwei Checks. Ich bin nicht jemand, der niedrig anfängt und graduell eskaliert. Ich gehe direkt auf max bei allem, was auch nur ansatzweise nicht-trivial aussieht.
Und gerade passiert das überall. Anthropic hat gerade offiziell Opus 4.6 auf "medium effort" als Standard für Max- und Team-Abonnenten umgestellt. Der Changelog-Post hat über tausend Likes gesammelt. Devs überall entdecken, dass diese Einstellung existiert, und eilen dazu, sie hochzudrehen. Wie Todd Saunders es ausdrückte: Die meisten Leute, die Claude Code verwenden, bekommen vielleicht 40% von dem, was das Modell mit den Standardeinstellungen kann.
Also ja. Ändere den Standard. Dieser Teil ist geklärt.
Jetzt die Zahl, die tatsächlich zählt: Meine schlimmsten Sessions, die 60-Nachrichten-Marathons, die in "partially_achieved" endeten, liefen auch auf /effort max. Dieselbe Slider-Position wie meine besten Sessions. Dasselbe Modell. Dasselbe extended thinking. Der Unterschied im Ergebnis war nicht die Effort-Stufe.
Es ist wie zwei Küchen mit exakt demselben Profi-Ofen zu haben. Ein Koch hat die Vorarbeit im Vorfeld mit strukturierten Prompt-Verträgen gemacht. Der andere hat einfach die Temperatur hochgedreht und auf das Beste gehofft. Derselbe Ofen. Sehr unterschiedliche Abendessen.
(Die /insights-Daten loggen nicht, welche Effort-Stufe pro Conversation-Turn aktiv ist, nur wenn du den Slash-Befehl tippst. Diese Analyse basiert also auf beobachteten Mustern, nicht auf direkter Effort-zu-Ergebnis-Korrelation pro Nachricht. Das Muster ist trotzdem schwer zu ignorieren.)
21 Mal max effort. Auch meine schlimmsten Sessions.
Was trennt die Sessions, die One-Shots sind, von den Sessions, die spiralen? Die Antwort zeigte sich in den 2-Nachrichten-Sessions.
Die echte Variable: Was passiert, bevor du die Aufgabe tippst
Hier ist, was meine tatsächliche Session-Historie zeigt, wenn du nach Effizienz sortierst.
Sessions, wo /effort max das Ergebnis verändert hat: komplexes Refactoring mit Non-Regression-Tests (Session 8fd1e558). Das Skelett für mein Buch über Prompt-Verträge schreiben (Session ae7d6686). Architektur-Bugs, wo Claude über mehrere Dateien gleichzeitig reasoning betreiben musste. Aufgaben mit echter Ambiguität, wo das tiefere Reasoning des Modells tatsächlich etwas Nützliches zu kauen hatte.
Sessions, wo /effort max nichts verändert hat: falscher Repo-Kontext ("nein, der Astro-Blog, nicht dieser hier"), Scope-Drift, wo Claude anfing, Dateien zu modifizieren, die ich nie erwähnt hatte ("warum hast du ollama angefasst, das habe ich nicht verlangt"), mehrdeutige Eröffnungsprompts, wo ich meine Frustration beschrieb statt die Aufgabe zu beschreiben.
Und die Sessions, die One-Shots waren? Die 2 bis 4 Nachrichten-Sessions, die komplexe Aufgaben beim ersten Versuch lösten?
Sie öffnen alle gleich.
"Implement the following plan:" gefolgt von einem strukturierten Kontext-Block.
Vier meiner zehn effizientesten Sessions verwenden exakt dieses Präfix. Eine 2-Nachrichten-Session mit strukturiertem Plan übertrifft konsistent eine 60-Nachrichten-Session mit /effort max und ohne Upfront-Kontext. Jedes einzelne Mal in meinen Daten. Es ist nicht mal knapp. Die 2-Nachrichten-Sessions fühlen sich fast langweilig an, wie jemandem dabei zuzusehen, wie er einem Rezept folgt. Die 60-Nachrichten-Sessions fühlen sich an wie ein Raid ohne Tank und ohne Healer. Alle haben maximalen DPS, aber die Party wiped trotzdem.
Die Aufschlüsselung, die dabei herauskam, ist nicht kompliziert:
/effort max zählt, wenn die Aufgabe echte architektonische Ambiguität hat. Mehrere Dateien, nicht-offensichtliche Dependencies, Reasoning, das erfordert, mehrere Constraints parallel zu halten. Für diese Aufgaben ist max effort die extra Response-Zeit wert.
Ein strukturierter Plan im Vorfeld zählt bei allem anderen. Routine-Features, Bug-Fixes, Migrationen, alles wo du weißt, wie das Ergebnis aussehen sollte, aber das Modell nicht genug Kontext hat, um in die richtige Richtung zu gehen.
Für kritische Aufgaben willst du beides. Plan zuerst, max effort zweitens. Diese Kombination macht One-Shots.
(Ein Caveat, das zählt: "Implement the following plan:" funktioniert, wenn der Plan tatsächlich strukturiert ist. Ein vager Plan plus max effort gibt dir dasselbe Ergebnis wie ein vager Prompt plus max effort. Die Qualität des Plans ist die Variable, nicht seine formale Präsenz.)
"Implement the following plan:" schlägt /effort max ohne Kontext. Jedes Mal.
Was Boris Plan-Modus nennt, was meine Daten "Implement the following plan:" nennen, es ist dasselbe Prinzip. Und es fehlt in 90% der Claude Code Workflows, die ich online sehe.
Ändere den Standard. Dann ändere, was du davor setzt.
Der Medium-Standard ist eine Entscheidung, die Anthropic für Kostenmanagement im großen Maßstab getroffen hat. Keine Empfehlung für deinen Workflow. Das Changelog bestätigt es. Wenn du einen Max- oder Team-Plan hast und immer noch auf medium läufst, lässt du Capability auf dem Tisch liegen. Wechsle zu high als deine Baseline. Reserviere /effort max für Aufgaben mit echter architektonischer Komplexität, die Art, wo Claude über mehrere Dateien reasoning betreiben und mehrere Constraints im Kopf behalten muss. Bei mechanischer Arbeit (Deploys, Pushes, repetitive Migrationen) reicht high und ist merklich schneller.
Aber wenn das Ändern des Sliders das Einzige ist, was du änderst, wirst du mehr Token ausgeben, um zur selben falschen Antwort mit mehr Confidence zu gelangen.
Garry Tan optimierte die Review-Ebene, um Fehler zu fangen, nachdem Claude Code schreibt. Die meisten Devs optimieren den Slider, die rohe Power des Modells. Keiner von beiden adressiert den tatsächlichen Bottleneck: was Claude versteht, bevor es anfängt zu arbeiten. Die Input-Ebene. Die, die bestimmt, ob all diese Processing-Power in die richtige Richtung geht oder in eine Wand.
Drei Dinge zum Merken.
Eins: Ändere den Standard von medium auf high bei der Installation. Es ist eine Anthropic-Entscheidung zur Verwaltung von Infrastrukturkosten, keine Empfehlung für deinen Workflow. Das Changelog bestätigt es, es ist erledigt, weiter.
Zwei: /effort max kompensiert keinen schlechten Starting-Kontext. Meine 25 Befehle zeigen es. Boris Cherny wusste das von Anfang an. Deshalb hat er Plan-Modus an einem Sonntagabend programmiert, bevor er je darüber geredet hat, welches Modell man verwenden soll.
Drei: Die Sequenz, die funktioniert, ist deprimierend banal. Ein strukturierter Plan. "Implement the following plan:". /effort max. In dieser Reihenfolge. Es ist nicht glamourös. Aber es ist das, was meine 2-Nachrichten-Sessions, die One-Shots sind, gemeinsam haben, und was meine 60-Nachrichten-Sessions nicht haben.
Der /effort-Slider ist das Letzte, was man anfassen sollte, nicht das Erste.
Quellen & Links
Boris Cherny über Claude Code Workflows, Plan-Modus und das Opus-Kosten-Paradox: YC Light Cone Podcast, Pragmatic Engineer Podcast, Lenny's Podcast (2025-2026).
Anthropic Changelog über Opus 4.6 Medium Effort Standard für Max/Team-Abonnenten: @ClaudeCodeLog.
(*) Das Cover ist AI-generiert. Boris' Plan-Modus wurde auch in 30 Minuten generiert, also ist das Cover wenigstens in guter Gesellschaft.