Token-Kosten senken: Kosten je akzeptierter Coding-Aufgabe

Zurück

Kevin Riedl

11 Min Lesezeit · 17. August 2026
Zuletzt geprüft 5. Oktober 2026

Weiter

Ein Coding-Agent kann weniger Tokens senden und trotzdem eine höhere Rechnung verursachen. Cache-Lesezugriffe, frische Eingaben, Cache-Schreibzugriffe und Ausgaben haben unterschiedliche Preise. Ein scheinbar günstiger Lauf kann außerdem Arbeit auf ein zweites Modell oder einen menschlichen Reviewer verlagern. Entscheidend ist: Was kostet eine tatsächlich akzeptierte Änderung?

Geprüft am 5. Oktober 2026. Dieser Artikel zeigt die Messung und schrittweise Optimierung eines bestehenden Coding-Workflows. Er ist keine Rangliste günstiger Modelle. Das Rechenbeispiel verwendet synthetische Abrechnungsdaten, keinen Wavect-Benchmark und kein Sparversprechen.

1. Erst die Rechnung normalisieren

Protokolliere Aufgaben-ID, Versuchs-ID, Modell und Version, Anbieter, Token-Kategorien, Preise, Werkzeugkosten, Latenz und Abnahmeergebnis. Abgelehnte Versuche und Hilfsagenten gehören dazu. Ein Fehlversuch bleibt im Kostenzähler; dieselbe Aufgabe darf nicht durch mehrere Abnahmen den Nenner vergrößern.

Anthropic weist ungecachte input_tokens getrennt von Cache-Erstellung und Cache-Lesezugriffen aus. Unterscheide beim Schreiben fünf Minuten und eine Stunde Gültigkeit. Die üblichen Schreibmultiplikatoren sind 1,25× und 2×. Lesen kostet meist 0,1× des Basiseingabepreises, bei Opus 5.5 jedoch 0,05× und bei Fable 5.1/Mythos 5.1 0,025×. Das sind modellspezifische Abrechnungskategorien, kein einheitlicher Token-Preis.

Verwende nicht denselben Parser für alle Anbieter. Bei OpenAI enthält die gesamte Eingabe bereits gecachte Tokens; Modelle mit cache_write_tokens erfordern zusätzlich die getrennte Erfassung der Schreibzugriffe. Ermittle normale Eingaben anhand der dokumentierten Felder ohne Doppelzählung. Fehlende oder widersprüchliche Nutzungsdaten sind ein zu klärender Abrechnungsfehler, nicht automatisch null Kosten. Berechne Ausgaben und Reasoning nach den Abrechnungsregeln des Anbieters.

2. Wiederholten Kontext cachebar machen und messen

Halte wiederverwendbare Anweisungen und Werkzeugdefinitionen stabil. Veränderliche Aufgabendaten gehören nach Möglichkeit später in den Präfix. Prüfe modellspezifische Mindestlängen, Ablaufzeiten sowie tatsächliche Lese- und Schreibzähler. Claude Code kann den Cache nach Änderungen oder Inaktivität neu aufbauen; Unteragenten können einen anderen Präfix haben. Eine längere Gültigkeit kostet beim Schreiben mehr und ist nicht automatisch günstiger.

3. Routing und Komprimierung an Abnahmekriterien binden

Bewerte Routing anhand eines festen Satzes von Repository-Aufgaben mit deterministischen Tests und Review-Kriterien. Ein günstigeres Modell übernimmt die Aufgabenklassen, die es nachweislich bewältigt. Änderungen mit hohem Risiko gehen gegebenenfalls direkt in eine stärkere Verifikation oder menschliche Prüfung. Selbsteingeschätzte Konfidenz oder gültiges JSON beweisen keine korrekte Codeänderung. RouteLLM ist eine Implementierungsreferenz, kein Nachweis garantierter Einsparungen in deinem Repository.

Kürze irrelevante Logs, lade nur benötigte Dateien und halte ein kompaktes Aufgabenmanifest vor. Bewahre Anforderungen, Dateiversionen, Fehlerbelege und den Zugriff auf vollständige Informationen. Miss zusätzliche Zusammenfassungsaufrufe, verlorene Cache-Wiederverwendung und Folgeversuche. Kürzerer Kontext garantiert weder geringere Kosten noch höhere Genauigkeit. Das dritte Beispiel zeigt bewusst eine Verschlechterung der Cache-Nutzung.

Eine konkrete Umsetzung behandelt unsere Analyse von RTK AI 1.0: Shell-Filter, optionale Pipelines und API-Proxy, einschließlich der Lizenzgrenzen und der Aussagekraft seiner Einsparungsstatistik.

4. Deterministische Arbeit ersetzen, unabhängige Jobs bündeln

Nutze Formatter, Parser, Suche und eng begrenzte Skripte für deterministische Arbeit. Miss tatsächlich entfallende Aufrufe, statt eine feste Prozentzahl zu behaupten. Berechtigungsprüfungen und Reviews bleiben bei destruktiven Operationen erforderlich. Bündle unabhängige Auswertungen oder Klassifizierungen, wenn die Latenz es erlaubt, aber keine interaktiven Schritte, die auf der vorherigen Antwort aufbauen. OpenAI dokumentiert für unterstützte Batch-Anfragen 50 % Rabatt und ein Abschlussfenster von 24 Stunden, nicht für alle Anbieter oder Workflows.

5. Den Unterschied zwischen Tokens und Kosten nachrechnen

Verwende in allen Szenarien dieselben zwei Fehlerbehebungsaufgaben und Abnahmekriterien. Jedes illustrative Szenario enthält drei Versuche, davon einen abgelehnten, sowie zwei unterschiedliche akzeptierte Änderungen. Die Token-Zähler summieren alle Versuche. Gerechnet wird mit den am 5. Oktober geprüften Sonnet-5.5-Standardpreisen je Million Tokens: 2 USD ungecachte Eingabe, 2,50 USD Schreiben für fünf Minuten, 4 USD Schreiben für eine Stunde, 0,20 USD Lesen und 10 USD Ausgabe. Batch- oder regionale Modifikatoren sind nicht eingerechnet.

Nur für dieses Beispiel kommen pro Szenario insgesamt 30 Review-Minuten zu angenommenen 60 USD/Stunde und weitere Workflow-Kosten von 0,40 USD hinzu. Das sind Rechenannahmen, keine gemessenen Stundensätze oder Werkzeugrechnungen. Ersetze sie im Betrieb durch tatsächliche Review-, Komprimierungs-, Infrastruktur- und Werkzeugkosten. Zähle die Tokens von Hilfsagenten nicht doppelt.

Das Szenario mit schlechterer Cache-Nutzung sendet weniger Tokens als das optimierte Szenario, kostet bei der API aber mehr. Review-Kosten verändern außerdem die wirtschaftliche Größenordnung des Vergleichs. Ohne akzeptierte Aufgabe ist der Kostenwert je akzeptierter Aufgabe nicht definiert. Weise den fehlgeschlagenen Lauf samt Ausgaben aus, statt durch null zu teilen oder eine Ersparnis zu behaupten.

Dieses Rechenbeispiel läuft mit Python 3.10 oder neuer. Es prüft die Arithmetik, nicht die Qualität des Agenten. Ersetze Zähler und Preise, bevor du damit deine eigene Rechnung bewertest.

from decimal import Decimal as D

# USD per million tokens: uncached, write 5m, write 1h, read, output.
RATES = tuple(map(D, ("2", "2.50", "4", "0.20", "10")))
CASES = {
    "baseline": (1_000_000, 200_000, 0, 8_000_000, 100_000),
    "optimized": (500_000, 200_000, 0, 4_000_000, 100_000),
    "cache_regression": (1_400_000, 0, 0, 0, 100_000),
}

def cost(tokens, accepted=2, review_minutes=30, other_usd="0.40"):
    if type(accepted) is not int or accepted <= 0:
        raise ValueError("accepted must be a positive count of unique tasks")
    if len(tokens) != len(RATES) or any(type(n) is not int or n < 0 for n in tokens):
        raise ValueError("provide five non-negative integer token counts")
    review, other = D(str(review_minutes)), D(str(other_usd))
    if not review.is_finite() or not other.is_finite() or min(review, other) < 0:
        raise ValueError("review time and other costs must be finite and non-negative")
    api = sum(D(n) * rate for n, rate in zip(tokens, RATES)) / D(1_000_000)
    review_usd = review / D(60) * D("60")
    return api, (api + review_usd + other) / D(accepted)

for name, tokens in CASES.items():
    api, per_accepted = cost(tokens)
    print(f"{name}: API=${api:.2f}; total/accepted=${per_accepted:.2f}")

6. Immer nur eine Änderung einführen

1. Vor Änderungen an Prompts oder Modellrouten einen Ausgangswert erfassen.
2. Eine Variable ändern: Präfixstabilität, Informationsabruf, Routing, deterministisches Werkzeug oder geeignete Batch-Verarbeitung.
3. Dieselben Aufgaben erneut ausführen und Fehler, akzeptierte Änderungen, Review-Zeit sowie die vollständige Rechnung erfassen.
4. Die Änderung nur behalten, wenn Qualität und Latenz akzeptabel bleiben und die gemessenen Kosten sinken.

Die übergreifende Kostenstrategie behandelt LLM-Token-Kosten senken. Für die Architektur gibt es den Multi-Modell-Coding-Agent-Leitfaden. Der Spotify-shunt-Review trennt weniger Hauptagent-Kontext von Hilfsagent-Kosten und Verifikationsaufwand.

Am 5. Oktober 2026 geprüfte Primärquellen

• Anthropic: Cache-Abrechnung und modellspezifische Preise
• Claude Code: Gültigkeit, Präfixänderungen und Nutzungszähler
• OpenAI: Cache-Abrechnung und explizite Schreibzugriffe
• RouteLLM: Routing-Implementierung und Evaluation
• OpenAI: Batch API, Voraussetzungen, Preis und Abschlussfenster