Effort Level

Effort Level

Definition

Das Effort Level ist eine Einstellung, mit der gesteuert wird, wie viel Aufwand ein KI-Modell für die Bearbeitung einer Anfrage einsetzen soll. Je nach Anbieter heißt der Parameter beispielsweise reasoning_effort, effort, thinking_level oder thinking_budget.

Ein höheres Effort Level gibt dem Modell typischerweise mehr Spielraum für internes Schlussfolgern, Planung, Selbstkontrolle, Werkzeugaufrufe und die Untersuchung alternativer Lösungswege. Ein niedrigeres Level priorisiert Geschwindigkeit und geringere Kosten. Der Regler verändert damit nicht nur, wie lange ein Modell „nachdenkt“, sondern kann auch beeinflussen, wie gründlich es recherchiert, wie viele Dateien es untersucht, wie oft es Tests ausführt oder wie umfassend es eine Antwort prüft.

Effort Level ist kein vollständig standardisierter Begriff. Die Bezeichnungen ähneln sich zwar, ihre technische Bedeutung unterscheidet sich jedoch zwischen OpenAI, Anthropic, Google, xAI und DeepSeek. Selbst innerhalb eines Anbieters unterstützen nicht alle Modelle dieselben Stufen. Die Konfiguration muss deshalb immer anhand der Dokumentation des konkret verwendeten Modells geprüft werden.

Typische Effort-Level

Die folgende Einteilung beschreibt die verbreitete Bedeutung der Stufen. Sie ist eine praktische Orientierung und keine anbieterübergreifend garantierte Skala.

None oder deaktiviert

Bei none beziehungsweise deaktiviertem Thinking wird kein zusätzlicher Reasoning-Modus angefordert. Das Modell antwortet möglichst direkt aus seiner normalen Generierung.

Vorteile:

• niedrigste Latenz
• geringer Tokenverbrauch
• gut für einfache Klassifikation, Extraktion und Formatierung
• geeignet für interaktive Anwendungen mit sehr kurzer Reaktionszeit

Nachteile:

• schwächer bei mehrstufiger Logik
• höhere Gefahr vorschneller Antworten
• weniger gründliche Selbstkontrolle
• ungeeignet für schwierige Mathematik, komplexe Planung oder anspruchsvolle Fehlersuche

none bedeutet nicht bei jedem Anbieter und Modell exakt dasselbe. Manche Modellfamilien erlauben kein vollständiges Abschalten des Denkmodus.

Minimal

minimal lässt nur sehr wenig zusätzliches Reasoning zu. Das Modell kann bei Bedarf kurze interne Verarbeitung durchführen, soll jedoch möglichst schnell zu einer Antwort kommen.

Geeignet für: kurze Faktenfragen, einfache Tool-Aufrufe, Routing, Intent-Erkennung, Datenextraktion und klar definierte Transformationen.

Risiko: Der Unterschied zu einem vollständig deaktivierten Denkmodus ist nicht immer eindeutig. Bei komplexen Aufgaben kann das Modell trotz minimal etwas Reasoning verwenden oder eine zu oberflächliche Lösung liefern.

Low

low ist für kostensensitive und latenzkritische Anwendungen gedacht, bei denen ein gewisses Maß an Schlussfolgern hilfreich bleibt. Das Modell prüft typischerweise mehr als bei minimal, vermeidet jedoch lange Exploration.

Vorteile:

• gutes Verhältnis von Geschwindigkeit zu Qualität bei einfachen Aufgaben
• weniger Reasoning- und Ausgabetoken
• geeignet für große Anfragevolumen und Subagenten
• kurze, klar definierte Tool-Workflows können effizient bearbeitet werden

Nachteile:

• kann Randfälle und versteckte Abhängigkeiten übersehen
• bricht komplexe Untersuchungen möglicherweise zu früh ab
• führt tendenziell weniger Verifikations- oder Werkzeugschritte aus
• Ergebnisse schwanken stärker, wenn eine Aufgabe doch mehrstufiges Denken benötigt

Medium

medium ist die typische Balance zwischen Qualität, Kosten und Antwortzeit. Für viele Analyse-, Schreib-, Programmier- und Agentenaufgaben ist es ein sinnvoller Ausgangspunkt.

Vorteile:

• ausreichend tiefes Reasoning für viele Alltags- und Business-Aufgaben
• meist deutlich günstiger und schneller als höchste Stufen
• gutes Niveau für strukturierte Vergleiche, Codeänderungen und moderate Recherche
• reduziert die Gefahr, dass ein Modell einfache Aufgaben unnötig überanalysiert

Nachteile:

• bei sehr schwierigen Aufgaben möglicherweise nicht genug Exploration
• kann komplexe mathematische Beweise, lange Agentenschleifen oder subtile Softwarefehler verfehlen
• ist zwischen Anbietern nicht direkt vergleichbar

High

high priorisiert Antwortqualität und gründliche Bearbeitung. Das Modell erhält mehr Raum für Planung, interne Prüfung, alternative Lösungsansätze und Werkzeugnutzung.

Vorteile:

• bessere Leistung bei komplexer Logik, Mathematik und Programmierung
• gründlichere Analyse von langen Dokumenten oder Codebasen
• mehr Selbstkontrolle und häufig zuverlässigere Tool-Nutzung
• geeignet für mehrstufige Aufgaben, bei denen ein Fehler teuer ist

Nachteile:

• höhere Kosten und längere Wartezeit
• möglicherweise unnötig für einfache Anfragen
• kann zu Überanalyse, langen Antworten oder zusätzlichen Tool-Aufrufen führen
• maximale Qualität ist nicht garantiert; schlechte Daten oder unklare Ziele werden durch mehr Effort nicht automatisch korrigiert

Xhigh

xhigh ist eine erweiterte Stufe für besonders schwierige oder lang laufende Aufgaben. Sie wird nur von bestimmten Modellfamilien unterstützt.

Geeignet für: anspruchsvolle Coding-Agenten, tiefe Recherche, komplexe Debugging-Aufgaben, lange Tool-Ketten und Probleme, bei denen mehrere Strategien getestet werden müssen.

Nachteile: Die zusätzlichen Kosten können stark steigen, während der Qualitätsgewinn gegenüber high je nach Aufgabe klein bleibt. Bei klaren oder einfach überprüfbaren Aufgaben ist xhigh häufig wirtschaftlich nicht sinnvoll.

Max

max soll dem Modell die größtmögliche verfügbare Arbeits- und Reasoning-Tiefe erlauben. Es ist keine Garantie für unbegrenzte Rechenleistung, sondern die jeweils höchste vom Modell angebotene Stufe.

Vorteile: maximale Chance auf gründliche Exploration, umfangreiche Selbstprüfung und lange Agentenabläufe.

Nachteile: höchste Latenz und Kosten, Gefahr des Overthinkings sowie abnehmender Grenznutzen. max sollte für echte Grenzfälle reserviert und durch Evaluationen gerechtfertigt werden.

OpenAI

OpenAI verwendet in der API überwiegend den Parameter reasoning_effort. Die verfügbaren Werte hängen vom Modell ab. Die GPT-5.6-Familie mit GPT-5.6 Sol, Terra und Luna unterstützt laut Modelldokumentation die Stufen none, low, medium, high, xhigh und max.

Ältere oder spezialisierte Modelle können eine kleinere Auswahl besitzen. GPT-5.1 unterstützt beispielsweise nicht dieselbe vollständige Skala, während bestimmte Pro-Modelle auf eine feste hohe Reasoning-Stufe beschränkt sein können. Eine Anwendung sollte daher nicht davon ausgehen, dass jeder OpenAI-Modellname alle Werte akzeptiert.

Bei OpenAI beeinflusst ein niedrigeres Reasoning Effort vor allem die Menge des internen Reasonings. Dadurch sinken üblicherweise Antwortzeit und Reasoning-Tokenverbrauch. Für einfache Fragen oder klar abgegrenzte Transformationen sind none oder low oft ausreichend. medium ist ein guter Ausgangspunkt für allgemeine Analyse und Codearbeit. high, xhigh oder max eignen sich für schwierige Planung, komplexes Coding und Aufgaben mit umfangreicher Tool-Nutzung.

Ein Vorteil der breiten Skala ist die feine Abstimmung innerhalb derselben Modellfamilie. Ein Nachteil ist die modellabhängige Verfügbarkeit: Beim Wechsel zwischen Modellversionen muss geprüft werden, welche Stufen und Standardwerte tatsächlich gelten.

Anthropic Claude

Anthropic verwendet den Parameter output_config.effort. Bei aktuellen unterstützten Claude-Modellen sind je nach Modell low, medium, high, xhigh und max verfügbar. high ist üblicherweise der Standard.

Claude interpretiert Effort als Signal für den gesamten Arbeitsaufwand. Der Parameter kann nicht nur das interne Thinking, sondern auch die Länge und Gründlichkeit von Erklärungen, die Zahl der Tool-Aufrufe und den Detailgrad von Funktionsargumenten beeinflussen. Niedriger Effort führt tendenziell zu direkterem Vorgehen und weniger Werkzeugschritten. Höherer Effort kann mehr Planung, Exploration und Dokumentation erzeugen.

Bei neueren Claude-Modellen wird Effort häufig mit adaptivem Thinking kombiniert. Das Modell entscheidet dann abhängig von Aufgabenkomplexität und Effort, ob und wie tief es nachdenkt. Effort ist dabei ein weiches Steuerungssignal und kein garantiertes Tokenbudget.

Praktische Einordnung:

• low: schnelle Chats, Klassifikation, kleine Subagenten und hohe Anfragevolumen
• medium: ausgewogene Agenten- und Coding-Aufgaben
• high: schwierige Analysen, komplexer Code und anspruchsvolle Tool-Nutzung
• xhigh: lang laufende Coding- und Agentenarbeit mit umfangreicher Exploration
• max: seltene Grenzfälle, bei denen Kosten und Laufzeit gegenüber maximaler Fähigkeit zweitrangig sind

Ein Vorteil von Claude ist, dass Effort den vollständigen Arbeitsstil des Modells steuern kann. Ein Nachteil ist, dass höhere Stufen zusätzliche Tool-Aufrufe und längere Abläufe erzeugen können, obwohl die Aufgabe bereits mit weniger Aufwand lösbar wäre.

Google Gemini

Google bezeichnet den Regler bei aktuellen Gemini-3-Modellen als thinking_level. Typische Stufen sind minimal, low, medium und high. Welche Stufen unterstützt werden und welcher Standard gilt, hängt vom jeweiligen Modell ab.

Gemini 3.7 Flash verwendet beispielsweise standardmäßig medium und unterstützt low, medium und high. Andere Flash- und Flash-Lite-Modelle können zusätzlich minimal anbieten. Pro-Modelle beginnen häufig auf einem höheren Standardniveau und erlauben teilweise kein vollständiges Abschalten des Thinkings.

Bei Gemini 2.5 wurde stattdessen häufig ein numerisches thinking_budget verwendet. Dieses definierte einen Richtwert für die Zahl der Thinking-Token. Bei Gemini 3 und neueren Modellen wird die abstraktere Level-Einstellung empfohlen. thinking_level und thinking_budget sollten nicht gleichzeitig gesetzt werden.

Vorteile:

• klare Abstufung für schnelle Flash- und leistungsstärkere Pro-Anwendungen
• dynamisches Thinking kann den Aufwand an die konkrete Anfrage anpassen
• minimal und low sind für skalierbare Echtzeit- und Tool-Anwendungen nützlich

Nachteile:

• Modellvarianten unterstützen unterschiedliche Level
• minimal garantiert nicht immer vollständig deaktiviertes Thinking
• ältere und neuere Gemini-Generationen verwenden unterschiedliche Parameterkonzepte

xAI Grok

Die Grok-Modelle 4.5 und 4.6 unterstützen laut xAI den Parameter reasoning_effort mit low, medium, high und xhigh. Der Standard ist high; das Reasoning kann bei diesen Modellen nicht vollständig deaktiviert werden.

low eignet sich für latenzkritische Agentenaufgaben und einfache Tool-Aufrufe. medium ist für komplexere Datenanalyse und Long-Context-Aufgaben gedacht. high richtet sich an schwierige Mathematik und mehrstufige Logik. xhigh maximiert die Reasoning-Tiefe für besonders anspruchsvolle Probleme.

Bei Grok-Mehragentenmodellen kann ein ähnlich benannter Effort-Parameter eine andere Bedeutung besitzen und beispielsweise die Zahl zusammenarbeitender Agenten statt der Tiefe eines einzelnen Reasoning-Prozesses steuern. Dies zeigt, warum Parameter niemals allein anhand ihres Namens interpretiert werden sollten.

DeepSeek

DeepSeek unterstützt einen Thinking-Modus und bei aktuellen V4-Modellen die Stufen low, high und max. Der Standard ist high. Über kompatible API-Formate können zusätzliche Bezeichnungen akzeptiert werden, diese werden jedoch teilweise auf weniger interne Stufen abgebildet.

Bei DeepSeek V4 werden medium, high und xhigh beispielsweise auf dieselbe interne Stufe high abgebildet. minimal und low können auf low fallen, während max die höchste Stufe auswählt. Ein scheinbar feiner Regler in einer kompatiblen API bedeutet daher nicht automatisch, dass das Modell intern ebenso viele unterschiedliche Effort-Level besitzt.

DeepSeek kann den Thinking-Modus auch deaktivieren. Im aktivierten Modus sind bestimmte Sampling-Parameter möglicherweise wirkungslos oder nicht unterstützt. Anwendungen müssen außerdem beachten, wie Reasoning-Inhalte bei mehrstufigen Tool-Unterhaltungen weitergegeben werden.

Vergleich der Anbieter

Anbieter Parameter Typische Level Charakteristik OpenAI reasoning_effort none, low, medium, high, xhigh, max feine Reasoning-Abstufung, stark modellabhängig Anthropic output_config.effort low, medium, high, xhigh, max steuert Thinking, Antwortaufwand und Tool-Nutzung Google thinking_level minimal, low, medium, high dynamisches Thinking, unterschiedliche Standards je Gemini-Modell xAI reasoning_effort low, medium, high, xhigh Reasoning standardmäßig aktiv, bei unterstützten Grok-Modellen nicht abschaltbar DeepSeek reasoning_effort oder Thinking-Konfiguration low, high, max Kompatibilitätswerte können auf dieselbe interne Stufe abgebildet werden

Diese Level dürfen nicht als identische Leistungsstufen verstanden werden. high bei einem schnellen kleinen Modell ist nicht automatisch leistungsfähiger als medium bei einem größeren oder neueren Modell. Das Effort Level optimiert das Verhalten innerhalb eines bestimmten Modells; es ersetzt keinen Modellvergleich.

Effort Level und Modellwahl

Die Modellwahl legt die grundsätzliche Fähigkeitsgrenze, Geschwindigkeit, Kontextlänge und Preisstruktur fest. Das Effort Level bestimmt, wie intensiv das ausgewählte Modell diese Fähigkeiten für eine konkrete Anfrage nutzt.

Ein günstiges Modell auf high kann für strukturierte Routineaufgaben besser geeignet sein als ein teures Spitzenmodell auf low. Umgekehrt kann ein leistungsfähiges Modell mit moderatem Effort bei schwierigen Aufgaben zuverlässiger und teilweise wirtschaftlicher sein als ein schwächeres Modell, das viele erfolglose Reasoning- oder Tool-Schritte ausführt.

Für reale Systeme sollte daher nicht nur „Modell A gegen Modell B“ getestet werden, sondern Kombinationen aus Modell und Effort. Hilfreiche Messgrößen sind Erfolgsquote, Kosten pro korrekt gelöster Aufgabe, Latenz, Tool-Aufrufe, benötigte Wiederholungen und menschlicher Korrekturaufwand. Der Epoch Capabilities Index oder domänenspezifische Software-Engineering-Benchmarks können eine grobe Fähigkeitsorientierung geben, ersetzen aber keine eigenen Evaluationen.

Auswirkungen auf Kosten und Latenz

Höherer Effort erzeugt meist mehr Reasoning-Token und kann mehr sichtbare Ausgabetoken oder Tool-Aufrufe verursachen. Dadurch steigen variable API-Kosten und die Zeit bis zur endgültigen Antwort. Bei Agentensystemen kommen Kosten externer Werkzeuge, Suchanfragen, Codeausführung oder Computer Use hinzu.

Die Kosten steigen nicht zwingend linear. Ein hoher Effort kann eine Aufgabe im ersten Versuch korrekt lösen und dadurch Wiederholungen sparen. Niedriger Effort kann zwar pro Anfrage billiger sein, aber durch Fehler, Retries oder menschliche Nacharbeit insgesamt teurer werden. Diese Betrachtung entspricht dem Gedanken des Valuemaxxing: Entscheidend ist nicht der minimale Tokenverbrauch, sondern der höchste Wert pro Gesamtkosten.

Umgekehrt führt hoher Effort nicht automatisch zu einem besseren wirtschaftlichen Ergebnis. Wenn eine Aufgabe eindeutig, einfach prüfbar oder stark standardisiert ist, kann zusätzliches Reasoning nur Latenz und Kosten erhöhen. Eine systematische Token Minimization sollte deshalb unnötigen Aufwand vermeiden, ohne die Erfolgsquote zu gefährden.

Effort Level bei KI-Agenten

Bei Agenten beeinflusst Effort häufig mehr als eine einzelne Textantwort. Höhere Stufen können dazu führen, dass der Agent:

• einen ausführlicheren Plan erstellt
• mehr Quellen, Dateien oder Codebereiche untersucht
• zusätzliche Tool-Aufrufe ausführt
• alternative Lösungswege testet
• Ergebnisse häufiger verifiziert
• nach Fehlern länger iteriert

Das kann bei komplexen Aufgaben vorteilhaft sein, erhöht aber das Risiko langer oder unkontrollierter Schleifen. Ein hoher Effort ersetzt daher keine Grenzen für Iterationen, Zeit, Kosten und Berechtigungen. Solche Kontrollen gehören zum Loop-Engineering.

Bei strukturierten Tools über das Model Context Protocol sollte Effort mit klaren Tool-Beschreibungen, engen Berechtigungen und überprüfbaren Ergebnissen kombiniert werden. Ein Modell kann mit mehr Effort gründlicher arbeiten, aber auch mehr falsche oder unnötige Aktionen planen, wenn das Ziel oder die Werkzeugschnittstelle unklar ist.

Vorteile eines höheren Effort Levels

• bessere Leistung bei schwierigen, mehrstufigen Aufgaben
• mehr Planung und Berücksichtigung von Abhängigkeiten
• gründlichere Prüfung von Zwischenergebnissen
• höhere Chance, subtile Fehler und Randfälle zu erkennen
• bessere Nutzung langer Kontexte und komplexer Werkzeugketten
• stärkere Ergebnisse bei Mathematik, Coding und strategischer Analyse

Nachteile eines höheren Effort Levels

• höhere Token- und Tool-Kosten
• längere Antwortzeit und Time-to-First-Token
• Risiko unnötiger Exploration oder Overthinking
• potenziell mehr Tool-Aufrufe und größere Ausgaben
• schwerer vorhersehbare Laufzeit bei Agenten
• kein Schutz vor falschen Ausgangsdaten, Halluzinationen oder schlecht formulierten Zielen

Vorteile eines niedrigeren Effort Levels

• schnelle Reaktionszeiten
• geringere Kosten und höhere Skalierbarkeit
• direkteres Verhalten bei klaren Aufgaben
• weniger unnötige Tool-Aufrufe
• gut für Klassifikation, Extraktion, Routing und einfache Transformation

Nachteile eines niedrigeren Effort Levels

• weniger robuste Mehrschrittlogik
• geringere Fehlersuche und Selbstkontrolle
• höhere Wahrscheinlichkeit, Randfälle zu übersehen
• schwächere Ergebnisse bei langen Agenten- und Coding-Aufgaben
• mögliche Gesamtkostensteigerung durch Retries und Nacharbeit

Praktische Auswahl

Minimal oder None verwenden

Sinnvoll für Rechtschreibkorrektur, Formatkonvertierung, einfache Extraktion, Intent-Klassifikation, kurze Faktenantworten und deterministisch überprüfbare Aufgaben.

Low verwenden

Sinnvoll für große Anfragevolumen, einfache Assistenten, Routing-Agenten, kleine Codeänderungen und Tool-Aufrufe mit klarer Struktur.

Medium verwenden

Sinnvoll als Standard für allgemeine Wissensarbeit, Vergleiche, Content-Erstellung, Datenanalyse, moderate Programmierung und typische Business-Workflows.

High verwenden

Sinnvoll für anspruchsvolle Analysen, schwierige Mathematik, Debugging, Architekturentscheidungen, mehrstufige Recherche und Agenten mit mehreren Werkzeugen.

Xhigh oder Max verwenden

Sinnvoll für seltene, besonders schwierige Aufgaben, bei denen die Kosten eines Fehlers deutlich höher sind als zusätzliche Modellkosten. Beispiele sind komplexe Codebasis-Migrationen, lang laufende autonome Entwicklungsaufgaben oder tiefgehende Untersuchungen mit vielen Abhängigkeiten.

Dynamische Effort-Strategien

In Produktionssystemen muss nicht jede Anfrage mit demselben Effort ausgeführt werden. Eine dynamische Strategie kann zunächst die Aufgabenkomplexität einschätzen und anschließend das passende Level auswählen.

Eine weitere Möglichkeit ist ein Eskalationsverfahren:

1. einfache Aufgaben zunächst mit low oder medium bearbeiten
2. Ergebnis automatisch durch Tests oder Regeln prüfen
3. nur fehlgeschlagene Fälle mit high erneut ausführen
4. besonders schwierige Restfälle an xhigh, max oder einen Menschen eskalieren

Dieses Verfahren kann bessere Gesamtkosten erzielen als die pauschale Nutzung der höchsten Stufe. Voraussetzung ist ein verlässlicher Prüfer. Bei Code können dies Tests, Compiler oder Linter sein; bei strukturierten Daten Schema- und Plausibilitätsprüfungen; bei Textaufgaben ein separater Reviewer oder menschliche Stichproben.

Häufige Missverständnisse

Effort Level ist nicht die Antwortlänge

Ein höheres Level soll die Bearbeitung gründlicher machen, muss aber keine längere sichtbare Antwort erzeugen. Die gewünschte Länge sollte zusätzlich im Prompt festgelegt werden.

Effort Level ist nicht gleich Max Tokens

max_tokens setzt eine harte oder technische Obergrenze für generierte Token. Effort ist meistens ein weiches Verhaltenssignal. Ein hohes Effort Level kann durch ein zu niedriges Tokenlimit abgeschnitten werden.

Effort Level ist nicht die Temperatur

Die Temperatur beeinflusst die Zufälligkeit der Tokenauswahl. Effort beeinflusst, wie intensiv das Modell die Aufgabe bearbeitet. Bei manchen Reasoning-Modellen werden Sampling-Parameter eingeschränkt oder ignoriert.

Effort Level ist nicht die Modellgröße

Ein höheres Effort Level verwandelt ein kleines Modell nicht in ein größeres Spitzenmodell. Es kann nur die vorhandenen Fähigkeiten intensiver nutzen.

Mehr Effort ist nicht immer besser

Bei einfachen Aufgaben kann mehr Reasoning zu unnötiger Komplexität führen. Die beste Stufe ist die niedrigste, die die erforderliche Qualität zuverlässig erreicht.

Evaluation und Best Practices

Effort sollte mit realen Aufgaben aus dem eigenen Einsatzgebiet getestet werden. Ein aussagekräftiger Test enthält leichte, mittlere und schwierige Fälle sowie bekannte Randfälle. Für jedes Level werden mindestens Qualität, Kosten, Latenz und Fehlerrate gemessen.

Die Auswahl sollte nicht nur anhand einer durchschnittlichen Benchmark-Punktzahl erfolgen. Wichtig ist die wirtschaftliche Erfolgsquote pro Aufgabe. Wenn ein höheres Level nur geringfügig bessere Ergebnisse liefert, aber Kosten und Laufzeit stark erhöht, ist eine niedrigere Stufe mit gezielter Eskalation häufig sinnvoller.

Empfehlenswert ist außerdem, Effort explizit zu konfigurieren, statt sich dauerhaft auf wechselnde Anbieterstandards zu verlassen. Bei Modell-Upgrades müssen die Tests wiederholt werden, weil sich Standard-Level, unterstützte Werte und die Bedeutung einer Stufe ändern können.

Abgrenzung

Das Effort Level ist ein Steuerungsparameter für die Intensität der Modellbearbeitung. Es ist kein Qualitätsversprechen und keine universelle Vergleichsskala zwischen Anbietern. Die optimale Einstellung hängt von Modell, Aufgabe, Tool-Zugriff, Kostenstruktur, gewünschter Latenz und der Möglichkeit automatischer Verifikation ab.

Als Grundregel gilt: Mit dem niedrigsten Effort starten, der die benötigte Qualität zuverlässig erreicht, und nur bei messbarem Nutzen erhöhen.