KI-News · Werkzeuge

Caveman gegen die
eingebauten Ausgabestile.

15. September 2026 · Lesezeit ca. 9 Minuten

Claude Code bringt vier eingebaute Ausgabestile mit: Default, Concise, Explanatory und Learning. Caveman ist ein separat installierter Skill mit demselben Ziel wie Concise, weniger Tokens in der Antwort. Ich habe dieselbe kleine Aufgabe an echtem PlantWiz-Code fünfmal beantwortet, einmal je Stil, und Zeichen sowie Wörter gezählt.

Die Aufgabe

backend/scripts/import-trefle.ts ruft bei einem Rate-Limit (HTTP 429) der Trefle-API die Funktion trefleGet nach 5 Sekunden Wartezeit rekursiv erneut auf, ohne Obergrenze. Hält die API das Limit dauerhaft, läuft der Import unbegrenzt weiter, ohne sichtbaren Fehler. Auftrag an den Agenten: „Begrenze die Anzahl der Wiederholungen bei Rate-Limits, damit das Skript nach ein paar Versuchen mit einer klaren Fehlermeldung abbricht.“

Fünf Stile, eine Aufgabe

Ich schaue mir die Funktion trefleGet an: Bei einem 429 (Rate-Limit) wartet
sie 5 Sekunden und ruft sich selbst erneut auf, ohne Obergrenze. Hält die
Trefle-API das Limit dauerhaft, läuft der Import unbegrenzt weiter, ohne
sichtbaren Fehler.

Ich ergänze einen Zähler-Parameter, der bei jedem Rate-Limit-Treffer hoch-
gezählt wird, und breche nach fünf Versuchen mit einer Fehlermeldung ab.
Die bestehende Wartezeit bleibt unverändert.

[... Code ...]

Ich habe trefleGet um den Parameter retries erweitert, Standardwert 0. Ab
dem sechsten Versuch wirft die Funktion einen Fehler statt weiter zu
rekursieren, die Meldung nennt die Anzahl der Versuche. Bestehende Aufrufe
der Funktion sind nicht betroffen, weil der neue Parameter optional ist.

trefleGet bricht jetzt nach fünf Rate-Limit-Versuchen mit Fehler ab, statt
endlos zu rekursieren.

[... Code ...]

Wartezeit zwischen Versuchen bleibt bei 5s.

★ Insight ─────────────────────────────────────
Unbegrenzte Rekursion bei Rate-Limits wirkt harmlos, kann ein Skript bei
einer länger anhaltenden API-Störung aber stundenlang ohne sichtbaren
Abbruch blockieren. Eine feste Obergrenze macht den Fehlerfall sichtbar.
Ein wachsendes Zeitintervall zwischen Versuchen (exponentielles Backoff)
wäre der nächste sinnvolle Schritt, hier bewusst weggelassen, um die
Änderung klein zu halten.
─────────────────────────────────────────────────

[... Code ...]

★ Insight ─────────────────────────────────────
Der neue Parameter retries ist optional mit Standardwert 0, bestehende
Aufrufe von trefleGet bleiben unverändert lauffähig. Dieses Muster, ein
optionaler Zähler-Parameter für rekursive Hilfsfunktionen, taucht in
PlantWiz noch an anderen Stellen auf und lohnt sich als wiederkehrendes
Erkennungsmerkmal für ähnliche Fehlerklassen.
─────────────────────────────────────────────────

Die Anzahl maximaler Versuche und die Reaktion danach sind eine Design-
Entscheidung mit mehreren vertretbaren Antworten. Dafür überlasse ich
Ihnen die Kernzeile.

async function trefleGet(url: string, retries = 0): Promise<any> {
  ...
  if (res.status === 429) {
    // TODO(human): Abbruchbedingung nach zu vielen Rate-Limit-Versuchen
    console.warn('\nRate-Limit erreicht, warte 5s...')
    await sleep(5000)
    return trefleGet(url, retries + 1)
  }
  ...
}

In backend/scripts/import-trefle.ts, in der markierten Zeile: Entscheiden
Sie, wann trefleGet aufgeben soll. Zwei vertretbare Richtungen: nach einer
festen Anzahl Versuche mit Fehler abbrechen (einfach, verliert aber alle
restlichen Pflanzen bei einer kurzen API-Störung), oder nur die aktuelle
Pflanze überspringen und mit der nächsten weitermachen (robuster,
verschleiert aber eine dauerhafte Störung im Log). Beides ist in der
bestehenden Codebasis vertreten, schauen Sie sich zum Vergleich an, wie
fetchDetail mit einzelnen Fehlern umgeht.

trefleGet: infinite retry on 429, no cap. Risk: dauerhaft rate-limited →
endless loop, kein Fehler sichtbar.

Fix: retries param, default 0. Cap 5. Über Cap: throw.

[... Code ...]

Wait 5s unchanged. Backoff wachsend: nicht drin, extra Schritt.

Gemessen

Fachlich ist der Code in allen fünf Antworten identisch, deshalb zählt die folgende Tabelle den Fließtext getrennt vom Codeblock, sowie zusätzlich beides zusammen als Gesamtlänge der Antwort:

Caveman und Concise verfolgen sichtbar dasselbe Ziel, kurzer Fließtext, landen aber nicht auf demselben Niveau: Concise ist mit 143 Zeichen noch einmal deutlich knapper als Caveman mit 230 Zeichen. Der Unterschied liegt am Muster selbst: Concise lässt Übergänge ganz weg, wo sie nichts zur Sache beitragen, Caveman kürzt jeden Satz, behält aber die Satzstruktur als Fragment bei, „Fix: retries param, default 0“ statt nur „retries param“.

Wofür Explanatory und Learning trotzdem etwas Eigenes bringen

Weder Concise noch Caveman ersetzen Explanatory oder Learning, weil sie ein anderes Ziel verfolgen. Explanatory erklärt warum eine Lösung so aussieht, in diesem Beispiel den Unterschied zwischen einer festen Obergrenze und echtem exponentiellem Backoff, eine Einordnung, die in der Caveman- oder Concise-Fassung schlicht fehlt. Learning geht weiter und überlässt die Design-Entscheidung, ob bei zu vielen Fehlversuchen die ganze Aktion abbricht oder nur einzelne Elemente übersprungen werden, bewusst dem Nutzer, mit Verweis auf ein bestehendes Vergleichsmuster im selben Code. Beide Stile kosten mehr Text, weil sie etwas anderes leisten als reine Kürzung.

Wann welcher Stil