Das günstigste Modell für Coding-Agenten ist dasjenige, das eine Änderung mit der niedrigsten Gesamtrechnung durch das Review bringt, nicht unbedingt das mit dem niedrigsten Input-Preis. Ein Agent sendet wiederholt Repository-Kontext, empfängt Tool-Ausgaben, führt Überlegungen durch, schreibt einen Patch und benötigt möglicherweise mehrere Korrekturen. Dieser Vergleich verwendet den Live-Modellkatalog-Snapshot von GetVibe vom 3. Oktober 2026 und konzentriert sich auf Modelle, die für Coding-Workflows eingesetzt werden können.
Preis-Snapshot des Katalogs
Die folgenden Werte sind USD pro eine Million Tokens, zuerst Input und anschließend Output. Die angezeigten Preisfelder werden aus dem GetVibe-Katalog aufgelöst; das Datum gibt an, wann dieser Vergleich geprüft wurde.
| Modell | Input-/Output-Rate | Bester erster Test |
|---|---|---|
| GPT-6 Luna | $0.0055 Eingabe · $0.0274 Ausgabe pro 1 Mio. Tokens | Kleine Korrekturen, Zusammenfassungen und schnelle Iteration |
| GPT-6.1 Sol | $0.1096 Eingabe · $0.548 Ausgabe pro 1 Mio. Tokens | Mehrstufige Änderungen und stärkeres Reasoning |
| GPT-6 Sol | $0.1096 Eingabe · $0.548 Ausgabe pro 1 Mio. Tokens | Mit 6.1 anhand bestehender Prompts vergleichen |
| Claude Sonnet 5.5 | $0.168 Eingabe · $0.84 Ausgabe pro 1 Mio. Tokens | Coding und Agent-Schleifen im Messages-Format |
Dies sind Katalogpreise und kein Benchmark-Ergebnis. Die Modellseite bleibt die aktuelle Quelle, falls sich die Preise nach dem 3. Oktober 2026 ändern. Claude Sonnet 5.5 ist für Claude Code nützlich, da es das Messages-Format akzeptiert; GPT-6-Modelle sollten über ein Responses-kompatibles Tool wie Codex CLI getestet werden, nicht über Claude Code.
Verwenden Sie einen Coding-Test, der abgeschlossene Arbeit misst
Wählen Sie drei Repository-Aufgaben: eine lokalisierte Fehlerbehebung mit einem fehlschlagenden Test, ein kleines Feature, das mehrere Dateien betrifft, und ein Refactoring mit der ausdrücklichen Vorgabe, das Verhalten nicht zu ändern. Fixieren Sie für jeden Durchlauf denselben Git-Commit, dieselben Anweisungen, Tool-Berechtigungen und denselben Testbefehl. Bewerten Sie, ob die Aufgabe korrekt gelöst wurde, ob die Tests bestehen, wie viele Korrekturdurchläufe erforderlich waren und wie lange die vollständige Änderung gedauert hat.
Vergleichen Sie nicht nur die finale Antwort. Ein Modell kann einen überzeugenden Patch erzeugen, der Tests nicht besteht und dadurch einen weiteren langen Durchlauf verursacht. Erfassen Sie die Input- und Output-Nutzung für jeden Durchlauf, einschließlich Tool-Ergebnissen und Korrektur-Prompts. Berechnen Sie die Kosten pro bestandener Änderung. Führen Sie pro Aufgabe mindestens einige Beispiele aus; eine glückliche Antwort ist kein stabiles Ranking.
Warum eine günstige Token-Rate trotzdem mehr kosten kann
Agenten senden häufig ein großes Präfix erneut: Systemanweisungen, Repository-Notizen, Tool-Schemas und den bisherigen Gesprächsverlauf. Output-Tokens können einen größeren Anteil an der Rechnung ausmachen, als kurze Prompts vermuten lassen. Ein Modell, das zwei Korrekturdurchläufe benötigt, kann teurer sein als eines, das pro Token mehr kostet, aber in einem Durchlauf einen funktionierenden Patch erzeugt. Cache-Lesevorgänge können die Wirtschaftlichkeit wiederholter Inputs verändern. Prüfen Sie jedoch, ob gecachter Input in der Nutzung ausgewiesen wird, bevor Sie Einsparungen berücksichtigen.
Halten Sie den Kontext fokussiert. Ignorieren Sie Build-Ausgaben, Abhängigkeiten, generierte Snapshots und nicht relevante Pakete. Bitten Sie den Agenten, zunächst nur wahrscheinliche Dateien zu untersuchen. Das reduziert die Token-Anzahl und verbessert häufig die Aufmerksamkeit. Nutzen Sie die Hinweise zum Prompt-Caching für stabile, wiederholte Präfixe.
Mit welchem Modell sollten Sie beginnen?
- GPT-6 Luna: eine sinnvolle kostengünstige Basis für routinemäßige, klar abgegrenzte Änderungen. Prüfen Sie die Modellseite auf Kontext und Funktionen und stufen Sie Aufgaben, bei denen es scheitert, hoch.
- GPT-6.1 Sol: Vergleichen Sie es bei Aufgaben, bei denen Planung und Reasoning über mehrere Dateien wichtig sind. In diesem Katalog-Snapshot ist es günstiger als GPT-6 Sol.
- GPT-6 Sol: Behalten Sie es in der Testmatrix, wenn Ihre bestehenden Prompts auf seinem Verhalten basieren; verwenden Sie gemessene Ergebnisse, um zu entscheiden, ob ein Wechsel hilfreich ist.
- Claude Sonnet 5.5: Beziehen Sie es für Claude Code und Messages-basierte Workflows ein. Sein Pfad und seine Tool-Semantik unterscheiden sich von Responses-basiertem Codex. Vergleichen Sie daher die Ergebnisse, anstatt so zu tun, als wären die Clients identisch.
Den Vergleich reproduzierbar machen
Verwenden Sie die OpenAI-kompatible API mit einem Schlüssel in der Umgebung für SDK-basierte Clients:
export GETVIBE_API_KEY="your-dashboard-key"
python - <<'PY'
import os
from openai import OpenAI
client = OpenAI(base_url="https://getvibeapi.com/v1", api_key=os.environ["GETVIBE_API_KEY"])
result = client.chat.completions.create(
model="gpt-6-luna",
messages=[{"role": "user", "content": "Untersuchen Sie src/parser.py und beheben Sie den fehlschlagenden Sonderfall. Führen Sie den relevanten Test aus."}],
max_tokens=1200,
)
print(result.choices[0].message.content)
PYVerwenden Sie genau den Endpunkt, den der Agent-Client unterstützt. Für Codex CLI verwenden Sie die Konfiguration für die Responses API; für Claude Code verwenden Sie die Messages-Konfiguration. Behalten Sie Berechtigungsabfragen bei und führen Sie Agenten in einem Branch aus, damit Sie einen konkreten Diff prüfen können.
Entscheidungsregel
Wählen Sie den günstigsten Kandidaten, der bei Ihren eigenen Repository-Aufgaben Ihre Zielquote für erfolgreiche Durchläufe und Ihr Latenzbudget erfüllt. Behalten Sie den festen Testsatz bei und führen Sie ihn erneut aus, wenn sich der Katalog, die Agent-Version oder der Prompt ändert. Speichern Sie Datum, Modell-ID, Nutzung und Testergebnis mit jeder Beobachtung. Der Katalog-Snapshot vom 3. Oktober 2026 ist über die Modellseiten verknüpft; verwenden Sie für die heutigen Preise diese Seiten, anstatt veraltete Werte in eine Tabelle zu kopieren.
Gesamtkosten einer Aufgabe schätzen
Trennen Sie für die Planung Input- und Output-Nutzung. Wenn eine Aufgabe 40,000 Input-Tokens und 2,000 Output-Tokens verwendet, berechnen Sie jeden Anteil anhand der aktuellen Raten pro Million des ausgewählten Modells und addieren Sie beide. Dies ist nur eine Basis: Gecachter Input, Mindestgebühren pro Anfrage, mehrere Agent-Durchläufe und Wiederholungen können die tatsächliche Rechnung verändern. Verwenden Sie nach einem Testlauf die Nutzungsdetails, um Schätzungen durch beobachtete Gesamtkosten zu ersetzen.
Verwechseln Sie die Kontextgröße nicht mit abgerechneten Tokens. Der maximale Kontext eines Modells beschreibt, was es akzeptieren kann, nicht, was jede Anfrage kostet. Verhindern Sie, dass der Coding-Agent das gesamte Repository lädt, wenn nur wenige Dateien relevant sind. Selektiver Kontext verbessert häufig die Antwortqualität und reduziert die Anzahl der gesendeten Tokens.
Qualitätssignale erfassen, die sich auf die Kosten auswirken
Erfassen Sie für jeden Durchlauf, ob der Patch sauber angewendet wird, ob die relevanten Tests bestehen, wie viele Tool-Aufrufe fehlschlagen, wie viele Korrekturdurchläufe erfolgen und ob ein Reviewer die Änderung akzeptiert. Ein Modell, das viele Wiederholungen benötigt, kann höhere Kosten pro akzeptierter Änderung verursachen, selbst wenn seine angezeigte Token-Rate niedriger ist. Auch die Latenz ist wichtig: Die langsamste Route kann für Aufgaben über Nacht geeignet, für einen interaktiven Editor aber ungeeignet sein.
Trennen Sie Modellfehler von Harness-Fehlern. Ein fehlender Testbefehl, ein veralteter Checkout oder eine verweigerte Berechtigung sollte nicht als Reasoning-Fehler bewertet werden. Bewahren Sie einen Trace mit Aufgaben-ID, Modell-ID, Repository-SHA und einer redigierten Fehlerkategorie auf, damit ein Team denselben Vergleich später wiederholen kann.
Verwenden Sie einen zweistufigen Workflow nur, wenn die Daten ihn stützen
Eine Kostenstrategie besteht darin, für routinemäßige Änderungen zunächst ein kostengünstigeres Modell zu verwenden und eine Aufgabe nach einem deterministischen Signal hochzustufen, etwa bei fehlschlagenden Tests oder einer ungültigen strukturierten Ausgabe. Das kann Geld sparen, wenn die meisten Aufgaben einfach sind. Bei schwierigen Aufgaben kann dadurch jedoch ein zweiter vollständiger Kontextdurchlauf entstehen. Messen Sie die Hochstufungsrate und die kombinierte Nutzung, bevor Sie diese Strategie einsetzen.
Halten Sie die Auswahl des Fallback-Modells in der Anwendungskonfiguration explizit fest. Wenn Reproduzierbarkeit wichtig ist, geben Sie an, welches Modell jede Aufgabe bearbeitet hat. Rufen Sie nicht stillschweigend ein anderes öffentliches Modell auf, während Sie einem Entwickler mitteilen, die Änderung stamme vom ursprünglichen Modell.