Wer in Web- und Softwareprojekten mit Sprachmodellen arbeitet, kennt die Diskussion: Welches Modell nehmen wir, und was kostet der Betrieb? Eine aktuelle Auswertung liefert dazu eine überraschend klare Zahl. Laut den Daten von Vercels AI Gateway – einer Zwischenschicht, über die Anwendungen Anfragen an verschiedene Modellanbieter leiten – entfielen im Juli 65,1 Prozent der Gesamtausgaben auf Anthropic. Verarbeitet wurden dort aber nur rund 30 Prozent der Tokens.

Ein Preisaufschlag, der akzeptiert wird

Tokens sind die Abrechnungseinheit von Sprachmodellen: kleine Text- oder Codebausteine, in die Eingaben und Ausgaben zerlegt werden. Rechnet man Ausgaben und Volumen gegeneinander, kostet ein Anthropic-Token im Schnitt 4,4-mal so viel wie ein Token der übrigen Anbieter im selben Gateway.

Bemerkenswert ist weniger der Aufschlag selbst als die Reaktion darauf. Entwicklerteams zahlen ihn offenbar bewusst, obwohl günstigere Alternativen technisch unmittelbar verfügbar wären – ein Gateway erlaubt den Modellwechsel typischerweise mit geringem Aufwand. Der naheliegende Schluss: In Aufgaben wie Codegenerierung und agentischen Abläufen, bei denen ein Modell mehrere Schritte selbstständig plant und ausführt, gewichten Teams Ergebnisqualität und Verlässlichkeit höher als den Tokenpreis. Belastbare Aussagen über die Gründe lassen die veröffentlichten Zahlen allerdings nicht zu; sie zeigen Ausgaben und Volumen, nicht Motive.

Warum der Tokenpreis allein wenig aussagt

Für die Budgetplanung ist der Preis pro Token eine trügerische Kennzahl. Entscheidend ist, wie viele Tokens eine Aufgabe verbraucht, bis das Ergebnis brauchbar ist. Ein günstigeres Modell, das mehrere Anläufe braucht, längere Kontexte mitschleppt oder Nacharbeit durch Entwicklerinnen und Entwickler erzeugt, kann in der Summe teurer sein als ein hochpreisiges Modell, das im ersten Durchlauf trägt.

Umgekehrt gilt das genauso: Nicht jede Teilaufgabe verlangt das teuerste Modell. Klassifikation, Zusammenfassung, Formatumwandlung oder einfache Extraktion lassen sich häufig mit kleineren, deutlich günstigeren Modellen abdecken. Die Ausgabenverteilung im Gateway spricht dafür, dass in der Praxis genau diese Aufteilung entsteht – ein großer Teil des Volumens läuft über günstige Modelle, ein großer Teil des Geldes über wenige, anspruchsvolle Anwendungsfälle.

Die Infrastruktur um das Modell herum

Zeitgleich zeigt eine zweite Entwicklung, dass die Modellwahl nur ein Teil der Rechnung ist. Artificial Analysis hat mit dem Search Index einen Benchmark veröffentlicht, der Such-APIs für KI-Agenten vergleicht – also Dienste, über die ein Agent Webinhalte recherchiert und abruft. Bewertet werden Qualität, Kosten und Geschwindigkeit.

Getestet wurden sieben Anbieter, als Modell kam GPT-5.6 Luna zum Einsatz. In der Auswertung liegen Parallel, Exa und Firecrawl vorn. Für Projektverantwortliche ist vor allem die Struktur des Benchmarks interessant: Er behandelt Suche als eigenständige Komponente mit eigenem Preis- und Latenzprofil, nicht als Nebensache des Modells.

Das entspricht der Realität agentischer Systeme. Ein Agent, der recherchiert, verursacht Kosten an mehreren Stellen: bei jedem Suchaufruf, beim Abruf und Aufbereiten der Inhalte und erneut beim Modell, das die zurückgelieferten Texte als Kontext verarbeiten muss. Eine Such-API, die präzise und knappe Ergebnisse liefert, senkt damit indirekt auch die Tokenkosten. Eine, die viel Rohtext ausschüttet, treibt sie hoch – selbst wenn ihr eigener Aufrufpreis niedrig ist.

Was das für die Budgetierung heißt

Aus beiden Meldungen lassen sich einige praktische Konsequenzen ableiten, ohne die Zahlen zu überdehnen:

  • Kosten pro Aufgabe messen, nicht pro Token. Sinnvolle Bezugsgröße ist der abgeschlossene Vorgang: ein bearbeitetes Ticket, ein generierter Pull Request, eine beantwortete Anfrage.
  • Modelle nach Aufgabenklasse trennen. Anspruchsvolle Code- und Agentenschritte rechtfertigen ein teures Modell, Routineschritte selten.
  • Wechselfähigkeit einplanen. Ein Gateway oder eine eigene Abstraktionsschicht hält den Anbieterwechsel im Bereich einer Konfigurationsänderung. Das ist bei den derzeitigen Preisunterschieden ein realer Hebel.
  • Suche und Abruf als eigene Kostenposition führen. Qualität, Preis und Latenz der Such-API wirken direkt auf Modellkosten und Antwortzeiten.
  • Benchmarks als Vorauswahl nutzen, nicht als Entscheidung. Der Search Index wurde mit einem bestimmten Modell erhoben; die eigenen Inhalte, Sprachen und Domänen können ein anderes Bild ergeben.

Grenzen der Datenlage

Bei der Interpretation ist Zurückhaltung angebracht. Die Ausgabenverteilung stammt aus einem einzelnen Gateway und einem einzelnen Monat. Sie spiegelt das Nutzungsverhalten der dort aktiven Entwicklerteams, nicht den Gesamtmarkt. Wer über dieses Gateway arbeitet, hat tendenziell ein bestimmtes Projektprofil – Web- und Anwendungsentwicklung mit starkem Code-Anteil. Dass Anthropic dort besonders präsent ist, muss in anderen Segmenten nicht gelten.

Auch die Faktorangabe von 4,4 ist ein Durchschnitt über Modelle, Kontextlängen und Abrechnungsarten hinweg. Sie taugt als Orientierung für die Größenordnung, nicht als Grundlage einer konkreten Kalkulation. Für die eigene Planung bleibt der Weg über Messwerte aus dem eigenen Betrieb.

Einordnung für Projekte

Für Web- und Softwareprojekte bedeutet das vor allem: KI-Kosten gehören von Anfang an ins Monitoring, aufgeschlüsselt nach Anwendungsfall und Komponente – Modell, Suche, Abruf. Wer diese Transparenz hat, kann Preisunterschiede von mehreren hundert Prozent gelassen betrachten und dort investieren, wo Qualität tatsächlich zählt. Und wer Modellwahl und Such-Infrastruktur austauschbar hält, bleibt in einem Markt handlungsfähig, in dem sich Preise und Ranglisten weiter bewegen werden.

Quellen