Agent Token Kosten reduzieren per CLI (2026 Anleitung)

Ein CLI-Codierungsagent fühlt sich frei, bis die Rechnung kommt. Man richtet Claude Code oder Codex auf ein Repository, bittet es, ein Modul zu refaktorisieren, und zehn Minuten später hat es vierzig Dateien gelesen, die Testsuite dreimal ausgeführt und Token in sechsstelliger Höhe für Kontext verbraucht, den es nie hätte sehen müssen. Multipliziert man das mit einem Team von acht Ingenieuren, die den ganzen Tag Agenten betreiben, ist die Rechnung keine Rundungsfehler mehr. Der Token-Verbrauch bei Codierungsagenten ist größtenteils Verschwendung, und das meiste davon lässt sich von der Kommandozeile aus beheben, ohne Modelle zu ändern oder schlechtere Ergebnisse in Kauf zu nehmen.

TL;DR

Senken Sie die Token-Kosten für Agenten, indem Sie den Kontext kürzen, bevor er das Modell erreicht: grenzen Sie den Arbeitssatz ein, halten Sie Speicherdateien kurz und komprimieren Sie lange Sitzungen. Aktivieren Sie das Prompt-Caching für stabile Präfixe (etwa 90 % Rabatt auf wiederholte Lesevorgänge). Leiten Sie günstige Unteraufgaben an ein kleines Modell weiter. Begrenzen Sie die Tool-Ausgabe. Messen Sie die Kosten pro Ausführung, damit Sie wissen, was sich tatsächlich geändert hat.

Einführung

Der Schmerz zeigt sich auf zweierlei Weise. Entweder stoßen Sie mitten in einer Aufgabe an eine harte Grenze, weil Sie ein Wochen- oder Sitzungslimit überschritten haben, oder die monatliche API-Rechnung kommt an und jemand fragt, warum ein „KI-Assistent“ mehr kostet als ein Junior-Mitarbeiter. Beides hat dieselbe Ursache: CLI-Agenten sind standardmäßig tokenhungrig. Sie lesen ganze Dateien, wenn sie nur zehn Zeilen benötigen, spielen die gesamte Konversation bei jeder Runde erneut ab, leiten die rohe Befehlsausgabe zurück in den Kontext und senden denselben System-Prompt und dieselbe Repo-Karte tausende Male am Tag erneut.

Nichts davon ist der Arbeit inhärent. Eine Refaktorisierung, die wirklich über 2.000 Token Code nachdenken muss, benötigt keine 180.000 Token Kontext, um dies zu tun. Die Lücke zwischen diesen beiden Zahlen ist Ihre Ersparnis, und fast alles davon kann mit Flags, Konfigurationsdateien und Gewohnheiten, die Sie heute annehmen können, wiederhergestellt werden.

Dieser Leitfaden erklärt, wohin Token bei einem CLI-Agentenlauf tatsächlich gehen, und bietet Ihnen dann konkrete Taktiken, um jeden Bereich zu reduzieren: Kontexthygiene und Speicherdateien, Prompt-Caching, Modell-Routing, Kürzen der Tool-Ausgabe und -Abrufung sowie Messung der Kosten pro Lauf, damit die Einsparungen real sind und keine Vermutung. Die Beispiele gehen von Claude Code und Codex aus, aber die Mechanismen gelten für jeden Agenten, der mit einer API kommuniziert, die Token abrechnet.

Ein weiterer, frühzeitig zu nennender Kostenfaktor: Ein Großteil der Token-Ausgaben von Agenten entfällt auf das Debugging. Ein Agent, der eine fehlerhafte interne API aufruft, wird es erneut versuchen, Fehlertexte lesen, Dokumente erneut lesen und in einer Schleife festhängen, wobei jede Iteration den vollen Preis in Token bezahlt.

Wohin die Token bei einem CLI-Agentenlauf tatsächlich gehen

Bevor Sie optimieren, benötigen Sie ein mentales Modell der Rechnung. Eine einzelne „Runde“ eines Agenten sendet eine Eingabe-Payload an das Modell und erhält eine Ausgabe-Payload zurück. Sie zahlen für beides, und bei den meisten Anbietern kostet die Ausgabe pro Token drei- bis sechsmal mehr als die Eingabe. Für eine führende Modellfamilie Mitte 2026 liegen die Eingabekosten bei etwa 3 $ pro Million Token und die Ausgabekosten bei etwa 15 $; ein günstigeres Modell derselben Familie kostet etwa 1 $ für die Eingabe und 5 $ für die Ausgabe. Betrachten Sie diese Zahlen als illustrativ, nicht als verbindliche Angebote; überprüfen Sie die aktuellen Preislisten, da Anbieter diese ändern. Der strukturelle Punkt bleibt unabhängig von den genauen Zahlen bestehen: Die Ausgabe ist teuer, und das Eingabevolumen ist das, was explodiert.

• System-Prompt und Tool-Definitionen. Die Anweisungen des Agenten plus das JSON-Schema jedes Tools. Pro Runde fest, oft 5.000 bis 15.000 Token, bei jeder einzelnen Runde erneut gesendet.
• Speicher- und Projektdateien. Dinge wie CLAUDE.md, Repo-Konventionen und persistente Anweisungen. Bei jeder Runde geladen, ob relevant oder nicht.
• Gesprächsverlauf. Jede frühere Benutzernachricht, Modellantwort, Tool-Aufruf und Tool-Ergebnis, bei jeder Runde vollständig wiedergegeben. Dies wächst unbegrenzt und ist normalerweise der größte Posten in einer langen Sitzung.
• Abgerufener Dateinhalt. Dateien, die der Agent gelesen hat. Ein einzelner Read einer 1.200 Zeilen langen Datei entspricht ungefähr 12.000 bis 18.000 Token, und Agenten lieben es, ganze Dateien zu lesen.
• Tool-Ausgabe. Test-Runner-Logs, npm install-Rauschen, git diff einer generierten Lockfile, Stack-Traces. Standardmäßig roh und ausführlich.

Die Ausgabe-Payload ist die Argumentation des Modells, Code-Änderungen und Erklärungen. Sie ist bei den meisten Läufen kleiner als die Eingabe, aber pro Token am höchsten bepreist, daher ist ein ausführliches „Lassen Sie mich meinen Plan in sechs Absätzen erklären“-Verhalten kostspielig.

Die wichtigste Tatsache: Der Gesprächsverlauf wird bei jeder Runde wiedergegeben. Eine 30-Runden-Sitzung kostet nicht das 30-fache einer Runde. Es ähnelt eher der Summe eines wachsenden Präfixes, sodass spätere Runden das volle Gewicht all dessen tragen, was vor ihnen lag. Deshalb ist eine lange, mäandernde Sitzung das Teuerste, was Sie tun können, und deshalb zielen die unten aufgeführten Taktiken unverhältnismäßig stark auf den Kontext ab, der erneut gesendet wird.

Wenn Sie einen tieferen Einblick wünschen, wie die Abrechnung von Sitzungen und Limits in der Praxis funktioniert, ist die Aufschlüsselung unter wie das Token-Fenster von Claude Code zurückgesetzt wird eine nützliche Ergänzung zu diesem Abschnitt; sie erklärt, warum eine Sitzung, die sich „kurz anfühlt“, dennoch ein Budget aufbrauchen kann.

Kontexthygiene und Speicherdateien

Das billigste Token ist das, das Sie nie senden. Kontexthygiene ist die wirkungsvollste Gewohnheit, weil sie die Eingabe-Payload bei jeder Runde für den Rest der Sitzung verkleinert.

Begrenzen Sie den Arbeitssatz, bevor Sie beginnen. Öffnen Sie keinen Agenten im Repo-Root und sagen Sie „Refaktorisieren Sie die Abrechnungslogik.“ Er wird sich verkriechen. Sagen Sie ihm stattdessen genau, welche Dateien wichtig sind:

# Anstatt eines vagen Prompts, der eine breite Erkundung auslöst:
claude "refactor the retry logic so it uses exponential backoff,
only in src/payments/retry.ts and its test file"

Das Benennen der Dateien verhindert, dass der Agent zwanzig Kandidaten liest, um die zwei relevanten zu finden. Wenn Sie ihn unbedingt explorieren lassen müssen, weisen Sie ihn auf ein Verzeichnis, nicht auf das Root-Verzeichnis.

Halten Sie Speicherdateien kurz und stabil. Eine CLAUDE.md (oder eine entsprechende Projekt-Speicherdatei) wird bei jeder Runde in den Kontext geladen. Teams behandeln sie wie ein Wiki und lassen sie auf 4.000 Token an Einarbeitungstext anwachsen. Bei beispielsweise 50 Runden pro Tag bei 8 Ingenieuren wird eine überladene Speicherdatei täglich hunderte Male ohne zusätzlichen Nutzen erneut gesendet. Überprüfen Sie sie:

# Grobe Token-Überprüfung Ihrer Speicherdatei (Zeichen / 4 ist eine gute Schätzung):
wc -c CLAUDE.md | awk '{print "≈", int($1/4), "tokens per turn"}'

Zielen Sie auf eine prägnante Datei ab: Build-/Testbefehle, feste Konventionen und Verweise auf tiefere Dokumentationen, nicht die Dokumente selbst. Wenn ein Abschnitt nur einmal im Monat für eine Aufgabe relevant ist, gehört er nicht in die immer geladene Datei. Verschieben Sie ihn in ein Dokument, das der Agent bei Bedarf liest.

Kompaktieren oder zurücksetzen Sie lange Sitzungen. Wenn eine Sitzung ihre Aufgabe erfüllt hat und Sie zu einer nicht verwandten Aufgabe wechseln, tippen Sie nicht weiter in denselben Kontext. Jede neue Runde zieht nun das gesamte alte Transkript mit sich. Verwenden Sie den Kompaktierungs- oder Löschbefehl des Agenten:

# In Claude Code, wenn das Gespräch lang wird:
/compact     # fasst den Verlauf in einem kurzen Überblick zusammen, verwirft das Roh-Transkript
# oder, für einen Neuanfang bei einer neuen Aufgabe:
/clear       # startet frisch; alter Kontext wird nicht mehr gesendet

/compact ersetzt typischerweise Zehntausende von Token aus dem rohen Verlauf durch eine Zusammenfassung, die ein Zehntel der Größe hat, und dieses kleinere Präfix wird dann bei jeder nachfolgenden Runde mitgeführt. Die Disziplin ist einfach: eine logische Aufgabe pro Sitzung, Kompaktierung oder Löschen zwischen den Aufgaben. Die Workflow-Muster in den Claude Code Workflows stützen sich stark auf diese Scoping-Gewohnheit, und es lohnt sich, sie vollständig zu übernehmen.

Verwenden Sie eine Projekt-Ignorierdatei. Halten Sie generierte Artefakte, Lockfiles, Build-Ausgaben und eingebundene Abhängigkeiten außerhalb der Reichweite des Agenten. Wenn der Agent dist/ oder node_modules/ nie sieht, gibt er nie Token für das Lesen oder Diffen dieser aus. Die meisten Agenten respektieren eine Ignorierdatei; konfigurieren Sie sie einmal, und die Einsparungen sind dauerhaft.

Prompt-Caching: Zahlen Sie nicht mehr den vollen Preis für dasselbe Präfix

Dies ist der größte Hebel für wiederholte Läufe, und er ist eher mechanischer als verhaltensbezogener Natur. Prompt-Caching ermöglicht es dem Anbieter, ein Präfix Ihrer Anfrage (Tools, System-Prompt, stabiler Kontext) zu speichern, sodass nachfolgende Anfragen, die dieses Präfix teilen, es mit einem erheblichen Rabatt zurücklesen, anstatt es neu zu verarbeiten.

Die Wirtschaftlichkeit, gemäß Anthropic's Prompt-Caching-Dokumentation: Ein Cache-Schreibvorgang kostet mehr als ein normales Eingabe-Token (etwa das 1,25-fache des Basiseingabe für den Standard-5-Minuten-Cache, etwa das 2-fache für einen 1-Stunden-Cache), aber ein Cache-Lesevorgang kostet etwa das 0,1-fache des Basiseingabe; das ist ein Rabatt von etwa 90 % auf den gecachten Teil. Da der Schreib-Aufschlag gering und der Lese-Rabatt groß ist, rechnet sich das Caching bereits nach einem einzigen Cache-Treffer beim kurzlebigen Cache und nach etwa zwei Treffern beim langlebigen Cache. Die Standard-Cache-Lebensdauer ist kurz (etwa 5 Minuten, wird bei jedem Treffer aktualisiert), mit einer 1-Stunden-Option. Es gibt eine Mindestgröße für das Caching; kleine Modelle und die größten Modelle benötigen ein paar tausend Token, bevor ein Präfix qualifiziert ist, daher hilft Caching am meisten genau dort, wo es wichtig ist: bei großen stabilen Präfixen.

Die strukturelle Regel besteht darin, stabilen Inhalt zuerst und flüchtigen Inhalt zuletzt zu platzieren und dann die Grenze zu cachen. Die Reihenfolge ist `tools → system → messages`, und jede Änderung invalidiert diese Ebene und alles danach. Sie möchten also, dass Zeitstempel, die eingehende Nachricht des Benutzers und frisch abgerufener Dateinhalt nach Ihrem Cache-Breakpunkt kommen, nicht davor.

Wenn Sie ein Modell direkt von Ihrem eigenen CLI-Wrapper aus steuern, stellen Sie dies explizit ein:

# Cache the stable prefix (system + tool defs + repo conventions).
# The volatile user turn comes after and is NOT part of the cached prefix.
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT + REPO_CONVENTIONS,   # stable across runs
            "cache_control": {"type": "ephemeral"},       # cache breakpoint here
        }
    ],
    messages=[{"role": "user", "content": user_task}],     # changes every run
)

# Inspect what actually got cached:
u = response.usage
print("cache write:", u.cache_creation_input_tokens)
print("cache read :", u.cache_read_input_tokens)   # these tokens billed ~10%
print("fresh input:", u.input_tokens)

Ein täglicher Refactor-Agent, der denselben System-Prompt und denselben 8.000-Token-Repo-Konventionsblock bei 60 Aufrufen pro Tag ausführt, ist der Lehrbuchfall. Ohne Caching zahlen Sie den vollen Eingabepreis für diesen 8.000-Token-Block 60 Mal. Mit Caching zahlen Sie den Schreib-Aufschlag einmal (oder einmal pro Cache-Ablauf) und die ~10% des Lesepreises die anderen Male. Allein für den Konventionsblock ist das eine Reduzierung von fast 90 %, und es summiert sich mit jeder anderen hier genannten Taktik.

Zwei Anmerkungen zum Betrieb. Erstens, halten Sie Ihr Präfix byte-stabil; ein einziges geändertes Zeichen vor dem Breakpoint zerstört den Cache und Sie zahlen erneut für einen Schreibvorgang. Legen Sie Ihren System-Prompt und Ihre Konventionen fest; fügen Sie keinen Zeitstempel ein. Zweitens ist der Cache standardmäßig kurzlebig, daher hält das Batching verwandter Läufe dicht beieinander (anstatt sie über den Tag zu verteilen) den Cache „warm“. Die OpenAI-API wendet einen ähnlichen Rabatt auf gecachte Eingaben automatisch bei unterstützten Modellen an; das Prinzip ist identisch, auch wenn die Feinheiten unterschiedlich sind. Die Free-Tier- und Routing-Tricks beim kostenlosen Betrieb von GPT-5.5 über Codex sind eine nützliche Ergänzung, wenn Caching allein nicht ausreicht.

Modell-Routing: Günstiges Modell für günstige Arbeit

Nicht jede Agentenaktion benötigt ein Frontier-Modell. Das Umbenennen einer Variable in drei Dateien, das Schreiben einer Commit-Nachricht, das Zusammenfassen eines Diffs oder das Generieren eines Boilerplate-Tests erfordert nicht dasselbe Modell, das eine Architektur entwirft. Doch das Standardverhalten der meisten CLI-Agenten ist es, alles während der gesamten Sitzung durch ein teures Modell laufen zu lassen.

Routing bedeutet, bewusst Aufgaben mit geringem Risiko an ein kleineres, günstigeres Modell zu senden und das teure Modell für echte Denkprozesse zu reservieren. Der Preisunterschied ist groß: Ein kleines Modell in einer bestimmten Familie kann drei- bis fünfmal billiger pro Token sein als das Flaggschiff, und für mechanische Aufgaben ist der Unterschied in der Ausgabequalität vernachlässigbar.

Praktische Möglichkeiten zum Routen von der CLI aus:

# 1. Wählen Sie das Modell pro Aufruf basierend auf der Aufgabe.
claude --model haiku   "write a conventional-commit message for the staged diff"
claude --model sonnet  "redesign the caching layer for the payments service"

# 2. Verwenden Sie ein günstiges Modell für die hochfrequente, risikoarme Schleife
#    (Commit-Nachrichten, Changelog-Einträge, schnelle Lint-Erklärungen)
#    und ein starkes Modell nur, wenn Sie explizit die schwierige Aufgabe aufrufen.

Stellen Sie den Standard auf das günstigere Modell ein und eskalieren Sie bewusst, anstatt standardmäßig das teure Modell zu verwenden und nie herunterzustufen. Die meisten Teams haben die Polarität umgekehrt: Sie verwenden das Flaggschiff für alles „zur Sicherheit“ und zahlen das Fünffache für Commit-Nachrichten.

Eine zweite Routing-Achse sind Unteragenten. Wenn Ihr Agenten-Framework das Delegieren einer eng gefassten Unteraufgabe an einen untergeordneten Agenten unterstützt, geben Sie diesem untergeordneten Agenten ein günstiges Modell und einen winzigen Kontext. Der untergeordnete Agent erledigt die Fleißarbeit (Suchen, Zusammenfassen, Entwerfen) für Cents und meldet ein kurzes Ergebnis an den teuren übergeordneten Agenten zurück, anstatt dass der teure übergeordnete Agent die Fleißarbeit selbst zum vollen Preis mit vollem Kontext erledigt. Die autonomen Schleifenmuster im Zielbefehl über Codex und Claude Code zeigen, wie diese Delegation strukturiert werden kann, sodass das teure Modell nur destillierte Ergebnisse sieht.

Eine Anmerkung zu Limits, nicht nur zu Dollars. Wenn Sie einen Plan mit Nutzungsobergrenze statt reinem Pay-as-you-go haben, dehnt das Routing auch aus, wie weit Ihr Kontingent reicht. Ihr Premium-Modellbudget für Commit-Nachrichten auszugeben, führt dazu, dass Teams bereits am Donnerstag an ihre Grenzen stoßen. Die kürzlich erfolgte Erhöhung des wöchentlichen Limits von Claude Code hilft, aber Routing ist immer noch das, was das Kontingent länger hält.

Kürzen der Tool-Ausgabe und des Abrufs

Die Tool-Ausgabe ist der heimliche Budgetkiller, weil sie unsichtbar ist, bis man hinsieht. Jeder Befehl, den ein Agent ausführt, gibt Text zurück, und dieser Text gelangt direkt zurück in den Kontext, wo er dann bei jeder nachfolgenden Runde wiedergegeben wird. Ein einzelnes npm install kann Tausende von Zeilen zurückgeben. Ein Testlauf mit ausführlicher Protokollierung kann Zehntausende von Token zurückgeben. Ein git diff, der eine neu generierte Lockfile enthält, kann enorm sein. Der Agent benötigt selten alles davon; er benötigt das Bestehen/Fehlschlagen und den relevanten Fehler.

Taktiken, die dies sauber reduzieren:

Machen Sie Befehle an der Quelle leise. Der Agent bezahlt für alles, was der Befehl ausgibt. Konfigurieren Sie Tools, um prägnant zu sein:

# Laut (Agent bezahlt für jede Zeile):
npm test

# Leise (nur Fehler und eine Zusammenfassung kommen zurück):
npm test --silent -- --reporter=dot

# Laut:
npm install

# Leise:
npm install --silent --no-audit --no-fund

Filtern Sie, bevor der Agent es sieht. Wenn Sie den Befehl steuern, den der Agent ausführt, leiten Sie das Rauschen heraus, sodass nur das Signal zurückgegeben wird:

# Nur die relevanten Zeilen kommen in den Kontext zurück:
pytest -q 2>&1 | tail -n 30

# Diff-Statistiken anstelle eines 4.000 Zeilen langen vollen Diffs:
git diff --stat

# Grep nach dem Fehler, anstatt das gesamte Log auszugeben:
npm test 2>&1 | grep -E "(FAIL|✗|Error)" | head -n 20

Bevorzugen Sie gezielte Lesevorgänge gegenüber dem Lesen ganzer Dateien. Das Lesen einer 1.500 Zeilen langen Datei, um eine Funktion zu ändern, ist reine Verschwendung. Ermutigen Sie den Agenten, nach dem Symbol zu greppen und ein Fenster darum herum zu lesen, nicht die gesamte Datei. Viele Agenten tun dies, wenn der Prompt sie dazu anregt („finde und lies nur die Funktion, die Wiederholungsversuche behandelt, nicht die ganze Datei“). Bei einer großen Datei ist das der Unterschied zwischen ~18.000 Token und ~800.

Begrenzen Sie den Abrufbereich. Wenn Ihr Agent Codebasis-Suchen oder RAG über Dokumente durchführt, begrenzen Sie, wie viele Chunks er zurückholt und wie groß diese sind. Zehn 200-Token-Schnipsel, die die Frage beantworten, schlagen fünfzig 800-Token-Schnipsel, die sie vergraben; Sie zahlen für jedes abgerufene Token, ob das Modell es verwendet oder nicht.

Diese Änderungen sind größtenteils einmalige Konfigurationen (Test-Reporter, Installations-Flags, eine Ignorierdatei) und zahlen sich bei jeder Ausführung dauerhaft aus, was sie zu einigen der besten Investitionen in Bezug auf den Aufwand in dieser gesamten Liste macht.

Messung und Zuordnung der Kosten pro Lauf

Sie können nicht verwalten, was Sie nicht messen, und „die Rechnung ist niedriger geworden“ ist keine Messung. Um zu wissen, ob eine Taktik funktioniert hat, benötigen Sie Kosten, die einem Lauf, idealerweise einer Aufgabe, zugeordnet sind.

Beginnen Sie mit den Daten, die Ihnen die API bereits liefert. Jede Antwort enthält ein Nutzungsobjekt. Erfassen Sie es:

u = response.usage
# Ungefähre Kosten in Dollar; ersetzen Sie die Live-Preise für Ihr Modell.
INPUT_RATE  = 3.00 / 1_000_000     # Basiseingabe $/Token (illustrativ)
OUTPUT_RATE = 15.00 / 1_000_000    # Ausgabe $/Token (illustrativ)
CACHE_READ  = 0.30 / 1_000_000     # ~10% der Basiseingabe
CACHE_WRITE = 3.75 / 1_000_000     # ~1.25x Basiseingabe (5-Minuten-Cache)

cost = (
    u.input_tokens          * INPUT_RATE  +
    u.output_tokens         * OUTPUT_RATE +
    u.cache_read_input_tokens  * CACHE_READ +
    u.cache_creation_input_tokens * CACHE_WRITE
)
print(f"run cost ≈ ${cost:.4f}  "
      f"(in={u.input_tokens} out={u.output_tokens} "
      f"cr={u.cache_read_input_tokens})")

Wenn Sie die Agenten-CLI anstelle Ihres eigenen Wrappers verwenden, funktionieren drei Ansätze:

# 1. Die meisten Agenten-CLIs bieten einen Nutzungs-/Kostenbefehl für die Sitzung.
#    Überprüfen Sie ihn nach einer repräsentativen Aufgabe und notieren Sie die Zahl.
claude /cost

# 2. Anbieterkonsolen melden die Ausgaben pro API-Schlüssel. Erstellen Sie einen dedizierten
#    API-Schlüssel pro Agent oder pro Projekt, damit die Ausgaben zugeordnet werden können,
#    anstatt in einer unauffindbaren Gesamtsumme zusammengefasst zu werden.

# 3. Markieren Sie Läufe. Umwickeln Sie den Agenten-Aufruf in einem Skript, das
#    Zeitstempel, Aufgabenbezeichnung und die gemeldeten Token-Zahlen in eine CSV-Datei protokolliert.
#    Eine Woche dieser CSV-Datei zeigt Ihnen, welche Aufgaben teuer sind.

Schätzen Sie, bevor Sie etwas Großes ausführen. Fügen Sie den Prompt und die Dateien, die Sie einschließen möchten, in einen Tokenizer ein (OpenAI's öffentlicher Tokenizer ist eine schnelle Möglichkeit, die Größe zu überprüfen) und schauen Sie sich die Anzahl an. Wenn „das gesamte Modul einschließen“ 90.000 Token sind und die gezielte Version 6.000 sind, haben Sie die Entscheidung gerade gesehen, bevor Sie dafür bezahlt haben.

Verfolgen Sie eine Zahl pro repräsentativer Aufgabe über die Zeit: Kosten pro „täglichem Refaktorierungsdurchlauf“, Kosten pro „PR-Überprüfungsdurchlauf“. Wenn Sie Caching aktivieren oder eine Unteraufgabe auf ein günstiges Modell umstellen, sollte sich diese Zahl ändern. Wenn nicht, tut die Taktik nicht das, was Sie denken, und Sie haben dies zum Preis eines Laufs statt einer Monatsrechnung gelernt.

Taktikvergleich

Die Einsparungsbereiche sind illustrativ und addieren sich multiplikativ; der Gewinn einer Taktik hängt von Ihrer Ausgangsverschwendung ab.

Fazit

Die Token-Kosten von Agenten sind größtenteils selbstverschuldet, und die Kommandozeile ist der Ort, an dem Sie sie beheben. Die Verschwendung liegt in Kontexten, die Sie erneut senden, Ausgaben, die Sie nicht lesen, und Modellen, die für die anstehende Aufgabe zu teuer sind. Beheben Sie diese, und die Rechnung sinkt, ohne die Qualität der Arbeit zu beeinträchtigen.

Erledigen Sie zuerst die Punkte mit geringem Aufwand; das Eingrenzen, die leise Ausgabe und eine schlanke Speicherdatei kosten nichts und zahlen sich von nun an bei jedem Lauf aus. Fügen Sie Caching und Routing hinzu, und der Unterschied ist die Art von Einsparung, die Sie in ein Budget aufnehmen können.