Claude Code Effort Level begrenzen: So wirkt maxEffortLevel

Die Kurzfassung

Zuerst auf Claude Code 2.1.267 oder neuer aktualisieren. Anschließend kommt "maxEffortLevel": "medium" in die Einstellungsdatei, deren Geltungsbereich zu den betroffenen Personen und Projekten passt: ~/.claude/settings.json setzt die persönliche, globale Obergrenze, .claude/settings.json gilt für alle Mitarbeitenden in einem Repository und verwaltete Einstellungen erzwingen eine unternehmensweite Regel.

Zulässig sind low, medium, high, xhigh und max. Der Wert max bedeutet, dass diese Quelle den Denkaufwand nicht begrenzt. Bleibt der Schlüssel ganz weg, gibt es ebenfalls keine Obergrenze.

Die Einstellung steuert den Denkaufwand, nicht das Budget. Sie begrenzt, wie intensiv Claude eine Anfrage bearbeiten darf. Ein Tokenkontingent, Kostenlimit oder Nutzungslimit eines Abonnements legt sie nicht fest. Diese Werte müssen separat über /usage, die Claude Console oder Claude Code OpenTelemetry gemessen werden.

Claude Code Effort Level: Was maxEffortLevel wirklich ändert

effortLevel und maxEffortLevel erfüllen unterschiedliche Aufgaben. Das Effort Level ist die für eine Sitzung oder ein Modell angeforderte Einstellung. Das maximale Effort Level bildet die Grenze, die diese Anforderung nicht überschreiten darf.

Steht die Obergrenze auf medium, können Entwickler weiterhin low oder medium wählen. Eine Anforderung von high, xhigh oder max wird stattdessen mit medium ausgeführt. Das Limit greift auch bei Effort-Vorgaben über /effort, die /model-Auswahl, --effort, CLAUDE_CODE_EFFORT_LEVEL und die Standardvorgabe des Modells. Claude Code wendet es vor jeder Anfrage im Client an. Deshalb funktioniert dieselbe Richtlinie auch dann, wenn der Modellverkehr über Anthropic, Amazon Bedrock, die Agent Platform von Google Cloud oder Microsoft Foundry läuft.

Die entscheidende Regel ist leicht zu übersehen: Von allen geladenen Geltungsbereichen gewinnt stets die niedrigste Obergrenze. Für normale Claude-Code-Einstellungen gilt üblicherweise eine Hierarchie, in der verwaltete Einstellungen über Befehlszeilenoptionen, Projektdateien und Benutzereinstellungen stehen. maxEffortLevel ist eine restriktive Ausnahme. Ein niedrigeres Projektlimit setzt sich auch dann durch, wenn eine verwaltete Quelle oder eine Benutzerquelle mehr zulässt.

Globale Obergrenze, Modellausnahme und strengeres Projektlimit einrichten

Zunächst claude --version prüfen. Ist die installierte Version älter als 2.1.267, muss vor dem Eintragen des Schlüssels claude update ausgeführt werden.

Für eine persönliche Obergrenze, die repositoryübergreifend gilt, gehört Folgendes in ~/.claude/settings.json:

{
  "maxEffortLevel": "medium",
  "modelSettings": {
    "claude-sonnet-4-6": {
      "maxEffortLevel": "max"
    }
  }
}

Der Wert auf oberster Ebene begrenzt jedes unterstützte Modell auf medium. Der Eintrag für Sonnet 4.6 ersetzt diesen Wert innerhalb dieser Benutzerdatei nur für Sonnet. max zwingt Sonnet nicht dazu, mit maximalem Denkaufwand zu arbeiten. Es bedeutet lediglich, dass diese konkrete Quelle das Modell nicht begrenzt.

Nun wird in .claude/settings.json eine strengere Regel für ein bestimmtes Repository ergänzt:

{
  "maxEffortLevel": "low"
}

Das wirksame Ergebnis ist bewusst restriktiv:

Die Modellausnahme durchbricht die Projektregel nicht. Sie hebt lediglich das mittlere Limit der Benutzerquelle für Sonnet auf. Genau hier entsteht am ehesten der falsche Eindruck, eine Ausnahme gelte uneingeschränkt.

Für eine Unternehmensrichtlinie lässt sich derselbe Schlüssel auf oberster Ebene über verwaltete Einstellungen ausrollen. Die Obergrenze gilt dann für alle von dieser verwalteten Quelle erfassten Personen und bei jedem unterstützten Provider. Ist zusätzlich für eine Enterprise-Rolle ein Effort-Limit hinterlegt, wendet Claude Code die jeweils niedrigere Grenze an.

Die Wirksamkeit der Obergrenze überprüfen

Eine gültige JSON-Datei beweist noch nicht, dass sich das beabsichtigte Limit durchgesetzt hat. Deshalb müssen sowohl die geladenen Quellen als auch die angewendete Stufe geprüft werden.

1. In Claude Code /status ausführen. Die Zeile Setting sources bestätigt, dass User settings, Project settings und gegebenenfalls Managed settings geladen wurden. Sie zeigt jedoch nicht, aus welcher Quelle jeder einzelne Schlüssel stammt.
2. Fehlt eine Quelle oder scheint ein neuer Schlüssel ignoriert zu werden, hilft claude doctor. Der Befehl listet abgelehnte Einstellungseinträge auf. Das veröffentlichte JSON-Schema kann einer neuen CLI-Version hinterherhinken; eine Warnung im Editor allein ist daher noch kein Urteil.
3. Die Sitzungsüberschrift neben dem Modellnamen kontrollieren. Claude Code zeigt dort das aktuelle Effort Level und bei Änderungen kurzzeitig auch in der Fußzeile an.
4. Im Beispiel-Repository /effort max anfordern. Die projektweite Obergrenze low gilt weiterhin. Eine höhere Anforderung kann sie nicht anheben.
5. Für nicht interaktive Flotten das Attribut effort für claude_code.cost.usage und claude_code.token.usage auswerten. Es protokolliert für jede Anfrage die tatsächlich angewendete Stufe zusammen mit Modell und Abfragequelle.

Der letzte Schritt ist bei Bedrock, Google Cloud und Foundry besonders wichtig. Die Richtlinie wird von Claude Code durchgesetzt, bevor die Anfrage den Provider erreicht. Die Telemetrie zeigt dagegen, welche Stufe Claude Code tatsächlich angewendet hat.

Qualität und Kosten getrennt testen

Ein mittleres oder niedriges Limit sollte nicht allein deshalb ausgerollt werden, weil die Bezeichnung sparsam klingt. Aussagekräftiger ist eine bekannte Routineaufgabe, die unter identischen Bedingungen verglichen wird.

Als Testaufbau eignet sich ein kleines Repository mit einem fehlschlagenden Parser-Test. Modell, Commit, Prompt, Berechtigungen und Toolzugriff bleiben in jedem Durchlauf gleich. Die Aufgabe lautet: den Randfall beheben, einen Regressionstest ergänzen, die Testsuite ausführen und die geänderten Dateien nennen. Zuerst läuft die unbegrenzte Basisvariante, danach wird der saubere Ausgangszustand wiederhergestellt und die begrenzte Variante ausgeführt.

Zunächst wird das Ergebnis bewertet, erst danach folgen die Kosten:

Entscheidend sind die Kosten pro akzeptierter Aufgabe, nicht die Tokens pro Antwort. Benötigt ein Durchlauf mit geringerem Denkaufwand ein zweites Review oder eine Nachbesserung, kann er teurer sein als ein sauberer Lauf mit höherem Effort Level. Dasselbe Prinzip gilt für den umfassenderen Vergleich der Claude Effort Levels. Die neue Einstellung macht die gewählte Obergrenze nun jedoch in Claude Code verbindlich.

Sieben Einsatzbereiche, in denen sich ein Effort-Limit auszahlt

Die folgenden Anwendungsfälle sind danach geordnet, für wen der operative Nutzen am klarsten ausfällt.

1. Plattformteams steuern Routinearbeit

Ein Plattformteam für 20 oder 200 Entwickler könnte medium über verwaltete Einstellungen vorgeben, niedrigere Stufen weiter zulassen und Richtlinienausnahmen nur auf Basis gemessener Ergebnisse gewähren. Der Nutzen liegt nicht allein in weniger Tokens. Eine einheitliche Standardgrenze über Laptops, IDE-Sitzungen und Cloud-Provider-Routen hinweg macht Vergleiche von Kosten und Qualität erst belastbar.

2. FinOps-Verantwortliche für API-abgerechnetes Claude Code

FinOps-Verantwortliche könnten eine verwaltete Obergrenze mit OpenTelemetry kombinieren und die Daten nach effort, Modell, Team und Kostenstelle gruppieren. Der Ablauf ist klar: zunächst die unbegrenzte Ausgangslage beobachten, dann das Limit für eine Pilotgruppe einführen und schließlich die Kosten pro akzeptierter Aufgabe vergleichen. Statt über ein vermeintlich teures Effort Level zu diskutieren, entsteht so ein Bericht, der die Kosten mit tatsächlich gelieferter Arbeit verknüpft.

3. Unternehmen mit Bedrock, Google Cloud oder Foundry

Ein reguliertes Unternehmen kann Modelle aus Beschaffungsgründen oder wegen seiner Datenkontrollen über die gewählte Cloud leiten. Da der Claude-Code-Client maxEffortLevel vor jeder Anfrage anwendet, lässt sich providerübergreifend eine einheitliche Effort-Richtlinie nutzen. Das schafft Richtliniengleichheit, ohne darauf warten zu müssen, dass jede Provider-Konsole dieselbe Steuerungsmöglichkeit anbietet.

4. CI-Verantwortliche mit wiederkehrenden Korrekturen

Teams, die Claude Code für Abhängigkeitsaktualisierungen, Formatierungskorrekturen, Testpflege oder Dokumentationsänderungen einsetzen, könnten diese Repositories auf low oder medium begrenzen. Die passende Stufe muss aus Testaufgaben abgeleitet werden. Bleibt die Qualität stabil, verhindert die Obergrenze jedoch, dass ein Flag, ein Skill oder ein Modellstandard Routineautomatisierung in einen tieferen Reasoning-Modus hebt.

5. Monorepo-Verantwortliche trennen Routine- und anspruchsvolle Arbeit

Für ein Monorepo ließe sich eine persönliche Obergrenze von medium beibehalten, während ein niedrigeres gemeinsames Limit in einem Repository für Dokumentation oder generierten Code hinterlegt wird und ein anspruchsvolleres System-Repository den größeren Spielraum behält. So trägt jedes Repository seine eigene Grenze. Die Kostenrichtlinie folgt der Arbeit, statt darauf zu vertrauen, dass alle Entwickler an einen Befehl denken.

6. Beratungen wechseln zwischen Kunden-Repositories

Berater könnten ein persönliches mittleres Limit als Ausgangspunkt nutzen und jedem Kunden-Repository erlauben, eine strengere gemeinsame Einstellung vorzugeben. Das reduziert Konfigurationsabweichungen, wenn derselbe Laptop zwischen einer kleinen Content-Website, einer etablierten Anwendung und einem kostensensiblen Wartungsvertrag wechselt. Zugleich dokumentiert die Projektdatei den vorgesehenen Betriebsmodus für die nächste Person.

7. Staff Engineers erhalten eine gezielte Modellausnahme

Ein Staff Engineer könnte über modelSettings ein Modell vom globalen Limit einer Quelle ausnehmen und in einem sicherheitskritischen Repository dennoch eine andere, niedrigere Obergrenze beibehalten. Das Modell erhält Spielraum, wo die Quelle ihn erlaubt, ohne dass die Ausnahme zum universellen Bypass wird. So entsteht eine präzise Ausnahme, die strengeren Projekt- oder Unternehmensrichtlinien untergeordnet bleibt.

Welche Produkte sich rund um das Limit lohnen

1. Effort-Regressions-Gate – die stärkste Chance

Denkbar ist ein CLI- und CI-Check, der die Sammlung abgenommener Aufgaben eines Repositories mit den erlaubten Effort Levels ausführt und Erfolgsquote, Reviewmängel, Dauer, Tokens und Kosten ausweist. Engineering-Plattformteams würden dafür bezahlen, weil das Limit unmittelbar eine Qualitätsfrage aufwirft: Wie niedrig lässt sich der Denkaufwand bei Routinearbeit ansetzen, bevor Nachbesserungen die Einsparung wieder aufzehren?

Das Nachfragesignal ist auffallend kommerziell. ai code review erzielt in den USA schätzungsweise 1,300 Suchanfragen pro Monat bei einem CPC von $62.38. Die kleinste verkaufbare Version wäre ein lokaler Runner mit einem GitHub Check, der zwei Effort-Profile am selben sauberen Testaufbau vergleicht und eine Richtlinienänderung blockiert, sobald erforderliche Tests fehlschlagen oder Reviewregeln verletzt werden.

Der Haken ist der Benchmark. Ein allgemeiner Coding-Score lässt sich leicht kopieren und hat wenig Bezug zum Repository eines Käufers. Verteidigungsfähig werden erst der private Aufgabenbestand des Teams, sein Reviewraster und die Historie über Modellaktualisierungen hinweg. Ohne diese Daten wäre das Produkt lediglich ein weiteres Dashboard.

2. Richtlinien-Linter für Claude Code Effort Levels

Ein schreibgeschützter Richtlinien-Inspektor könnte Benutzer-, gemeinsame Projekt-, projektlokale, Befehlszeilen- und verwaltete Quellen in einer Tabelle der wirksamen Obergrenzen pro Modell zusammenführen. Plattform- und Sicherheitsteams könnten damit eine fälschlich als global verstandene max-Ausnahme, ein unerwartet wirksames niedrigeres Projektlimit oder eine Flotte erkennen, die noch eine Version vor 2.1.267 nutzt.

claude code erreicht in den USA schätzungsweise 550,000 Suchanfragen pro Monat. Zu den aktuell gestellten Fragen gehört auch, welches Effort Level sich für Claude Code eignet. Dieses Volumen ist breit und noch keine direkte Kaufabsicht, doch die Konfigurationsverwirrung ist konkret. Für ein MVP genügen Quellenerkennung, Versionsprüfung, JSON-Validierung und eine Erklärung der niedrigsten wirksamen Obergrenze.

Das Plattformrisiko bleibt: Anthropic könnte eine eigene Ansicht der effektiven Einstellungen ergänzen. Ein dauerhaft relevantes Produkt müsste deshalb Abweichungen von Richtlinien melden, den Flottenbestand erfassen und Nachweise für Audits liefern – nicht nur einen hübscheren Einstellungsbildschirm.

3. Kostenüberwachung nach Effort Level für Claude Code

Ein fokussiertes OpenTelemetry-Dashboard könnte das angewendete Attribut effort mit Tokens, Kosten, Modell, Abfragequelle, Repository und Qualitätsprüfungen aus Anthropic- und Cloud-Provider-Umgebungen verknüpfen. FinOps- und Developer-Experience-Teams würden für die Verbindung zwischen Richtlinie und Ergebnis zahlen, nicht für eine weitere Token-Summe.

llm observability erzielt in den USA schätzungsweise 590 Suchanfragen pro Monat und einen CPC von $37.45. Bestehende Preise belegen ein verfügbares Budget: Datadog Agent Observability startet kostenlos mit 40,000 LLM Spans, während Pro bei $160 pro Monat für 100,000 Spans beginnt. Ein fokussiertes MVP könnte aus einer OpenTelemetry-Collector-Voreinstellung, einem Inventar der Obergrenzen und drei Ansichten bestehen: angewendetes Effort Level, Kosten pro akzeptierter Aufgabe und Regressionen nach einer Modell- oder Richtlinienänderung.

Die Schwierigkeit liegt in Konkurrenz und Kausalität. Observability-Anbieter erfassen bereits Tokens und Kosten. Eine niedrigere Rechnung nach Einführung eines Limits beweist außerdem nicht, dass das Limit die Ursache war. Das Produkt braucht Vergleichsevaluationen oder Belege aus einer Change-Point-Analyse, um Vertrauen zu verdienen.

Das Effort-Regressions-Gate ist von diesen drei Ideen die beste. Seine Nachfrage liegt am nächsten an einer bezahlten Engineering-Entscheidung. Zugleich gewinnt die private Evaluationshistorie jedes Mal an Wert, wenn Anthropic ein Modell oder die Kalibrierung der Effort Levels verändert.

Was die Obergrenze nicht leistet

Ein Effort-Limit garantiert keine niedrigere Rechnung. Der Denkaufwand beeinflusst Output-Tokens, Toolverhalten und Reasoning, doch auch Modellwahl, Codebasisgröße, Cacheverhalten und parallele Automatisierung wirken sich aus. Bei Abonnenten von Claude Max und Pro ist die Nutzung im Tarif enthalten; die unter /usage ausgewiesenen Sitzungskosten entsprechen daher nicht ihrer Rechnung.

Ebenso wenig ist low für jede Programmieraufgabe automatisch sicher. Anthropic empfiehlt ausdrücklich, die eigene Arbeitslast zu testen. Außerdem wird dieselbe Effort-Bezeichnung je nach Modell unterschiedlich kalibriert. Ein Durchlauf mit medium bei einem Modell steht nicht für eine feste Reasoning-Menge, die sich mechanisch mit medium bei einem anderen Modell vergleichen ließe.

Auch eine absolute Modellausnahme entsteht dadurch nicht. Ein modellspezifischer Eintrag mit max entfernt nur das Top-Level-Limit derselben Quelle. Eine andere Quelle kann weiterhin eine niedrigere Obergrenze setzen, und das Effort-Limit einer Organisation kann noch niedriger sein.

Schließlich bestätigt /status, welche Dateien geladen wurden, aber nicht, welche Datei für jeden Schlüssel gewonnen hat. In automatisierten Abläufen ist das Telemetrieattribut effort der eindeutigere Nachweis.

Der nächste Schritt am Montag

Für die kommende Woche eine Routineaufgabe aus einem Repository auswählen. Zuerst eine unbegrenzte Ausgangsmessung erfassen, dann auf Benutzerebene ein medium-Limit und die dokumentierte Sonnet-Ausnahme ergänzen und schließlich low in der gemeinsamen Projektdatei setzen. Anschließend geladene Quellen und Effort Level in der Sitzungsüberschrift prüfen, die Aufgabe vom selben sauberen Ausgangszustand wiederholen und zuerst die Ergebnisqualität, danach die /usage-Kosten vergleichen. Bleibt die Qualität stabil, kann die getestete Obergrenze in den passenden gemeinsamen oder verwalteten Geltungsbereich übernommen werden. Andernfalls wird für diese Arbeitslast das strengste Limit angehoben oder entfernt – zusammen mit den gesammelten Nachweisen.

Wenn für den eigenen Engineering-Workflow eine Effort-Richtlinie, ein Evaluations-Gate und Kostentelemetrie entstehen sollen, finden sich weitere Informationen unter KI-Produktionssysteme.