Anthropic-API-Preise 2026: alle Tarife und die echten Kostenhebel

Die vollständige Anthropic-API-Preistabelle

Alles Folgende stammt aus Anthropics eigener ausführlicher Preisdokumentation, Stand 13. August 2026. Die Preise sind in USD pro Million Token angegeben, was die Doku mit MTok abkürzt. Bevor Sie eine URL kopieren, sollten Sie wissen: platform.claude.com/docs/en/pricing ist ein Redirect-Stub, der nichts zurückgibt, die echte Seite liegt unter /about-claude/pricing.

Drei Dinge in dieser Tabelle sind einen zweiten Blick wert.

Fünf Opus-Generationen sind identisch preislich. Opus 5, 4.8, 4.7, 4.6 und 4.5 werden alle mit 5 $ ein und 25 $ aus abgerechnet. Wenn Sie aus Reproduzierbarkeitsgründen noch an einer älteren Opus-Version festhalten, sparen Sie damit kein Geld, und das ausgemusterte Opus 4.1 ist das einzige, das noch auf der alten 15-$-und-75-$-Tabelle steht.

Sonnet wurde günstiger, was normalerweise nicht so läuft. Sonnet 5 liegt bei 2 $ und 10 $ gegenüber 3 $ und 15 $ bei Sonnet 4.6 – ein Rückgang von 33 % auf beiden Zählern in einer Generation. Für die meisten Produktionslasten macht das Sonnet 5 zur offensichtlichen Standardwahl statt zu einem Kompromiss.

Fable 5 liegt mit 10 $ und 50 $ genau beim doppelten Preis von Opus 5. Merken Sie sich diese Zahl, sie taucht wieder auf, wenn wir zum Fast Mode kommen.

Wenn Sie zu den Preisen auch den Fähigkeitskontext der Claude-Modelle sehen möchten, sehen die Spezifikationen so aus:

Anthropics eigene Empfehlung lautet, mit Claude Opus 5 zu beginnen für komplexe agentenbasierte und Enterprise-Aufgaben, und Fable 5 als Reach-Modell statt als Standard zu behandeln.

Rechnen Sie Ihre eigene Zahl aus

Die Preistabelle wird erst zu einem Budget, wenn Sie Ihren eigenen Traffic durchrechnen. Stellen Sie die vier Werte unten ein, dann wird der Monat berechnet und Ihnen gezeigt, was dieselbe Last ohne Caching und ohne Batch-Rabatt gekostet hätte.

Bewegen Sie den Cache-Regler und beobachten Sie die Summe, denn dieser einzelne Regler bewegt die Zahl bei einer input-schweren Last stärker als ein Wechsel der Modellstufe. Das ist das ganze Argument des nächsten Abschnitts.

Vier Multiplikatoren entscheiden über die Rechnung, nicht die Preistabelle

Anthropic veröffentlicht den Preis pro Token prominent und die Multiplikatoren eher leise. Das Geld liegt in den Multiplikatoren.

Prompt-Caching ist der größte Hebel, und der kurze Cache ist der günstige

Caching hat drei Preise, alle relativ zum Basis-Input-Preis des Modells: Ein 5-Minuten-Cache-Write kostet 1,25x, ein 1-Stunden-Write kostet 2x, und ein Cache-Hit kostet 0,1x. Das Setzen der Breakpoints selbst ist kostenlos. Die Obergrenze im eingeschwungenen Zustand ist ein Rabatt von 90 % auf jedes wiederverwendete Präfix.

Bei der Break-Even-Rechnung liegen die meisten falsch. Jeder Treffer spart 0,9x der Basis, der 5-Minuten-Cache rechnet sich also nach einem Treffer, der 1-Stunden-Cache braucht zwei. Write plus ein Treffer bei der 1-Stunden-TTL ergibt 2,1x gegenüber 2,0x ohne Caching – ein Prompt mit einmaliger Wiederverwendung im langen Cache ist damit aktiv schlechter, als Caching einfach auszulassen.

Anthropics eigene Empfehlung lautet, beim 5-Minuten-Cache zu bleiben für alles, was öfter als alle fünf Minuten getroffen wird, weil er ohne zusätzliche Kosten aufgefrischt wird, sobald er genutzt wird. Die 1-Stunden-TTL ist für Lücken gedacht: einen langen Nebenagenten-Lauf oder einen Nutzer, der vielleicht zehn Minuten nicht antwortet.

Dann gibt es den Teil, den fast niemand einpreist. Cache-Reads werden nicht von Ihrem Input-Token-Rate-Limit abgezogen. Anthropics durchgerechnetes Beispiel ist ein 2.000.000-ITPM-Limit gepaart mit einer 80%igen Cache-Trefferrate, was es erlaubt, 10.000.000 Input-Token pro Minute über denselben Account zu schieben. Caching ist nicht nur ein Rabatt, es ist ein 5-facher Durchsatz-Multiplikator, und es ist der günstigste Weg, eine Obergrenze anzuheben, die Sie sonst von Anthropic anheben lassen müssten.

Haiku 3.5 ist die dokumentierte Ausnahme, bei der Cache-Reads doch auf das Limit angerechnet werden, und es ist auf der First-Party-API ohnehin ausgemustert.

Das ist auch der Grund, warum plakative Token-Zahlen so stark in die Irre führen. Ein Praktiker, der die Kostenschätzung eines anderen auf Hacker News korrigierte, brachte es so klar wie möglich auf den Punkt:

"i run a bunch of claude agents for automation and like 85% of input tokens end up being cached reads -which cost 1/10th of the sticker price. so your $200k number is probably closer to $25-30k in real cost"

tcbrah, Hacker News

Mehrere Leute, die Produktionsautomatisierung betreiben, berichten unabhängig voneinander, dass 85 % bis 92 % der Input-Token als Cache-Reads landen. Wenn Sie eine Token-Zahl zum Listenpreis bewerten, überschätzen Sie eine echte Rechnung um etwa das 10-Fache.

Das minimal cachebare Präfix ist die Falle, die sich darunter verbirgt, denn es verläuft nicht linear über die Generationen:

Opus 5 cached ab 512 Token. Haiku 4.5 braucht das Achtfache davon. Bleiben Sie unter dem Schwellenwert, tut Caching einfach nichts und gibt keinen Fehler zurück, weshalb eine Rechnung, die nach dem „Einschalten von Caching" nicht sinkt, meist an einem Prompt liegt, der die Bedingung nie erfüllt hat. Wenn sowohl cache_creation_input_tokens als auch cache_read_input_tokens in der Antwort bei null stehen, ist das der Hinweis.

Ein paar weitere Mechaniken, die still Geld kosten. Das Read-Lookback-Fenster umfasst 20 Blöcke, ein Turn, der mehr als 20 hinzufügt, schiebt sich also über Ihren letzten Write hinaus und verpasst den Treffer. Das Ändern von Tool-Definitionen macht den gesamten Cache ungültig, da die Hierarchie Tools, dann System, dann Messages durchläuft. Und der dokumentierte häufige Fehler ist, den Breakpoint auf einen Block mit einem Zeitstempel oder der eingehenden Nutzernachricht zu setzen, was bei jeder einzelnen Anfrage einen frischen Write erzeugt und nie einen Read.

Batch bringt pauschal 50 %, mit zwei Ausnahmen

Die Batch API gibt 50 % Rabatt auf Input und Output bei jedem aktiven Modell, und sie lässt sich mit Caching kombinieren. Die Limits liegen bei 100.000 Anfragen oder 256 MB pro Batch, die meisten sind innerhalb einer Stunde fertig, und die harte Obergrenze liegt bei 24 Stunden.

Das Abrechnungsdetail, das mir gefällt: errored, canceled und expired Anfragen werden überhaupt nicht abgerechnet. Nur Erfolge kosten Geld, was Batch zu einem risikoarmen Ort macht, um einen großen Klassifizierungsjob laufen zu lassen. Das Gegengewicht: Ein Batch kann Ihr konfiguriertes Ausgabenlimit wegen paralleler Verarbeitung leicht überschreiten, es ist also kein harter Budgetzaun.

Zwei Ausnahmen, mit denen Sie planen sollten: Batch kombiniert sich nicht mit dem Fast Mode, und der Rabatt gilt nicht für Managed-Agents-Sitzungen.

Effort ist die Standardeinstellung, die niemand setzt

output_config.effort steuert, wie viele Token Claude ausgibt, und das betrifft Text, Tool-Calls und Denken gleichermaßen, es greift also auch mit ausgeschaltetem Thinking. Die Stufen sind low, medium, high, xhigh, max.

Der Standard ist bei jedem von Anthropic dokumentierten Modell high, die zweitteuerste Einstellung auf der Leiter. Anthropics eigene Best-Practice-Liste beginnt mit „effort explizit setzen", was eine höfliche Art ist zu sagen, dass das Verhalten ab Werk nicht das ist, was Sie für Volumenarbeit wollen.

Für keine Stufe werden Token-Multiplikatoren veröffentlicht, behandeln Sie es also als Regler zum Messen statt als Rabatt zum Einfordern. Der einzige Vergleichsanker, den Anthropic gibt: Sonnet 5 bei medium entspricht ungefähr Sonnet 4.6 bei high. Zwei Fallen, die Sie vor dem Tuning kennen sollten: Das Ändern von Effort zwischen Anfragen macht Ihre gecachten Präfixe ungültig, die beiden Hebel bekämpfen sich also gegenseitig, und bei Opus 5 verkürzt ein niedrigerer Effort das Denken statt der sichtbaren Antwort – prompten Sie also für Kürze, wenn Sie darauf abzielen.

Die zwei Aufschläge, die sich in der Doku verstecken

Fast Mode gibt Opus 5 und Opus 4.8 bis zu 2,5-fach schnelleren Output zu 10 $ ein und 50 $ aus, genau doppelt so viel wie Standard. Das ergibt die Kaufentscheidung, die ich auf der gesamten Tabelle am interessantesten finde: Opus 5 im Fast Mode kostet exakt so viel wie Fable 5 im Standardmodus. Wenn Sie bei einem schwierigen Problem zum Fast Mode greifen, kalkulieren Sie erst das fähigere Modell zum gleichen Preis, bevor Sie sich festlegen. Fast Mode gibt es nur auf der First-Party-API, und er kombiniert sich nicht mit Batch.

Der leisere Aufschlag ist die Datenresidenz. Das Festlegen der Inferenz auf die USA mit inference_geo: "us" bei Claude 4.6 und neuer wendet einen 1,1x-Multiplikator auf jede Token-Kategorie an, und das schließt Cache-Writes und Cache-Reads ein, nicht nur Input und Output. Das ist ein 10%iger Aufschlag auf die gesamte Rechnung, leicht einmal gesetzt und vergessen, und globales Routing ist der standardmäßig bepreiste Default.

Stapeln Sie alle vier Hebel, und die Spanne bei einem einzigen Modell wird größer als die Lücke zwischen den Modellstufen:

Die Tool- und Agentenkosten, die auf die Token aufgesetzt werden

Serverseitige Tools werden separat abgerechnet, und das sind die Posten, die Leute überraschen, wenn sie zum ersten Mal eine Monatsrechnung lesen.

Diese letzte Zeile verdient eine Anmerkung, denn sie bewegt sich in die richtige Richtung. Opus 4.7 hatte mit 675 Token bei auto den schlechtesten festen Tool-Overhead auf der Tabelle, und Opus 5 hat ihn auf 286 gesenkt. Wenn Sie ein umfangreiches MCP-Tools-Setup mit Tausenden kleiner Anfragen betreiben, ist das eine echte Reduzierung von 58 % bei einem Kostenposten, den Sie nie selbst gewählt haben.

Anthropic veröffentlicht ein eigenes durchgerechnetes Beispiel für eine einstündige Managed-Agents-Coding-Sitzung auf Opus 5, und es ist die klarste Caching-ROI-Zahl, die sich irgendwo in der Doku findet:

Das ist ein Rückgang von 25,5 % über die gesamte Sitzung allein durch Caching, bei einer Last, in der Output dominiert und Caching nur einen Teil der Rechnung berühren kann.

Es gibt keinen Long-Context-Aufschlag mehr

Das ist die Änderung, die die meisten Drittanbieter-Preisbeiträge noch immer falsch darstellen. Claude 4.6 und neuer enthalten das volle 1-Mio.-Token-Fenster zu Standardpreisen, und die Preisdoku sagt es unmissverständlich: Eine Anfrage mit 900.000 Token wird zum gleichen Token-Preis abgerechnet wie eine mit 9.000 Token. Caching- und Batch-Rabatte gelten ebenfalls über das gesamte Fenster.

Zwei Einschränkungen verhindern, dass das ein Free Lunch ist. Anthropic selbst warnt, dass Genauigkeit und Recall mit wachsender Token-Zahl abnehmen, ein volleres Fenster zu bezahlen kann also schlechtere Antworten bedeuten. Und das Overflow-Verhalten hat sich bei Claude 4.5 und neuer geändert: Übersteigt Input plus max_tokens das Fenster, wird die Anfrage angenommen und stoppt mittendrin mit stop_reason: "model_context_window_exceeded", und Sie zahlen für alles, was bis zum Stopp generiert wurde.

Wie sich die Anthropic-API-Preise im Vergleich schlagen

Hier ist der ehrliche direkte Vergleich mit den anderen Frontier-APIs, entnommen von der jeweiligen Anbieterseite am selben Tag. Wenn Sie die ausführlichere Version wollen, haben wir eine vollständige Aufschlüsselung der drei API-Anbieter und einen direkten Vergleich mit der Anthropic API.

Liest man diese Tabelle fair, ist Claude nirgendwo das Günstigste. Gemini-Preise unterbieten Sonnet 5 beim Input in der Mid-Stufe, grok-4.6 ist beim Output in der Frontier-Stufe drastisch günstiger, und deepseek-v4-flash ist mit $0.14 und $0.28 in einem völlig anderen Universum, mit einem Cache-Read-Preis, der etwa 50-mal unter dem Preis ohne Cache-Treffer liegt.

Wo Anthropic gewinnt, ist Vorhersagbarkeit, und in großem Maßstab ist das echtes Geld wert.

Beginnen wir mit Long Context, denn kein aktuelles Claude-Modell verlangt dort einen Aufschlag, während Gemini 3 oberhalb von 200K einen verdoppelten Preis veröffentlicht. Die xAI-Variante ist härter: Ihr Long-Context-Preis gilt für alle Token der Anfrage, sobald der Prompt 200K überschreitet, ein Token zu viel bepreist also den gesamten Call neu. Vergleichen Sie dann die Form der Rechnung. Anthropic misst vier Dinge: Input, Output, Cache-Writes und Cache-Reads, plus eine kleine Menge benannter Tools. Die xAI-Seite listet fünf separat abgerechnete Token-Typen, sechs bepreiste Tool-Aufrufe, Datei- und Collection-Speicher, Egress, und eine Gebühr von 0,05 $ für jede Anfrage, die gegen die Nutzungsrichtlinien verstößt. Auch Batch-Parität ist ein Mythos: OpenAI rabattiert jeden Zähler, Google hält Context Caching bei seinen Pro-Batch-Zeilen auf Standardpreisen, und xAI gibt grok-4.6 überhaupt keinen Batch-Rabatt.

Es gibt außerdem eine Besonderheit, die Sie kennen sollten, wenn Sie nach Preis einkaufen. DeepSeek veröffentlicht eine Base-URL im Anthropic-Format unter api.deepseek.com/anthropic, was bedeutet, dass das SDK, das Sie gegen Claude geschrieben haben, mit einer Base-URL-Änderung meist auf ein deutlich günstigeres Modell zeigt. DeepSeeks eigene Seite warnt zudem vor einer kommenden deutlichen Preiserhöhung, behandeln Sie die heutige Zahl also eher als Untergrenze denn als Plan. Wenn die Rechnung der Grund ist, warum Sie das hier lesen, ist unsere Übersicht der Claude-Alternativen der richtige Ausgangspunkt. Das günstigere Open-Weight-Ende wird separat behandelt, mit Preisen pro Modell für Qwen und für Kimi K2.5.

Warum öffentliche Claude-API-Rechnungen sich um vier Größenordnungen unterscheiden

Wenn Sie danach suchen, was die Anthropic API in der Praxis kostet, finden Sie Zahlen, die unmöglich dasselbe Produkt beschreiben können. Es lohnt sich zu verstehen, warum, bevor Sie eine davon als Benchmark nehmen.

Fast alle lauten Zahlen stammen von Entwicklern, die einen Coding-Agenten direkt auf einen rohen API-Key ansetzen. So sieht das aus:

"At API prices it's incredibly easy to burn cash. I ran through my Claude Max 20x last week and had $100 credit from when Anthropic banned OpenClaw, so I decided to use it to get some chores done. Three hours of very light work on Sonnet cost me $55."

u/satansxlittlexhelper, Reddit

Beachten Sie, dass das Sonnet ist, nicht Opus, und er beschreibt die Arbeit als sehr leicht. Im selben Thread berichtet ein anderer Entwickler von einer Spitzen-Verbrauchsrate von etwa 50 $ pro Stunde, und jemand anderes verlor 300 $ in zwölf Stunden durch einen unbeaufsichtigten Nachtlauf. Ein Kommentator nennt den konkreten Fehlermodus, der diese Zahlen erzeugt: 20 $ verloren an einen Agenten, der in einer Tool-Call-Schleife feststeckte, was ein Argument für Spend-Caps und Loop-Guards ist, nicht für den Preis.

Jetzt dieselbe API, im selben Thread, bei begrenzter Arbeit:

"I'm using the API to relevance classify hundreds of articles a day. Been running for 2 ish weeks, I think I'm almost up to $2 in cost"

u/warnerbr0, Reddit

Fünfzig Dollar pro Stunde und zwei Dollar in zwei Wochen, auf derselben Preistabelle. Die Variable ist nicht die Preisliste, sondern ob die Last einen begrenzten Prompt und begrenzten Output hat oder eine Agentenschleife, die selbst entscheidet, wie viel sie ausgibt. Fast jede Behauptung „die Claude API ist teuer", die Sie lesen werden, misst das Zweite, und fast jede serverseitige Produktintegration ist das Erste.

Die praktische Lesart: Ignorieren Sie Pro-Stunde-Zahlen komplett, wenn Sie eine normale Integration dimensionieren, und modellieren Sie stattdessen Ihre eigene Token-Form.

So sieht die Rechnung bei drei realen Workloads aus

Listenpreise sagen nicht viel aus, bis man sie an eine konkrete Aufgabe hängt. Alle drei unten nutzen veröffentlichte Preise, und die Rechnung ist dieselbe, die das Widget oben ausführt.

Ein Support-Triage-Klassifikator. 50.000 Tickets pro Monat, Haiku 4.5, ein 3.000-Token-Anweisungsblock, der bei jedem Call wiederverwendet wird, plus 400 Token Tickettext, und 150 Token Output. Das ergibt 170 $ Input und 37,50 $ Output, also etwa 208 $ pro Monat oder vier Zehntel Cent pro Ticket. Im Batch nochmal halbiert. Das ist die Last, bei der die rohe API tatsächlich fast kostenlos ist, und deshalb muss sich eine Pro-Ticket-Preisgestaltung bei einem Support-Tool gegen etwas so Günstiges erst verdienen.

Ein Coding-Agent. 2.000 Sitzungen pro Monat auf Opus 5, 60.000 Input-Token pro Sitzung mit 80 % aus dem Cache, und 12.000 Output-Token. Der Input ergibt 120 $ ungecacht plus 48 $ Cache-Reads, und der Output 600 $. Macht rund 768 $, wobei Output 78 % davon trägt. Bei agentenbasierten Workloads ist der Output-Zähler die Rechnung, Caching hilft also deutlich weniger, als der Rabatt-Schlagzeile suggeriert. Das ist das mit Abstand Nützlichste, was man wissen sollte, bevor man die Kosten eines Agenten modelliert.

Ein einmaliger Dokumenten-Backfill. 200.000 Dokumente, Sonnet 5, 5.000 Token ein und 800 aus, über Batch gefahren. Der Input liegt bei 1.000 $ zum 1-$-Batch-Preis und der Output bei 800 $ zu 5 $, also 1.800 $ für den Lauf gegenüber 3.600 $ synchron. Hier gibt es nichts zu cachen, da jedes Dokument anders ist, und genau für diese Form existiert Batch.

Das Muster über alle drei hinweg: Caching gewinnt bei input-schwerem, sich wiederholendem Traffic, Batch gewinnt bei allem, worauf man warten kann, und keines von beiden bringt viel für einen Agenten, der viel schreibt. Passen Sie den Hebel an die Form der Arbeit an.

Wo die rohe API aufhört, die günstige Option zu sein

Alles oben bepreist Token. Es bepreist nicht das System darum herum, und genau dort kippt die meiste Build-versus-Buy-Rechnung still und leise.

Ich habe die letzten Jahre damit verbracht, KI-Agenten auf lebende Support-Queues zu setzen, und das Muster in Sales-Calls ist konsistent genug, um vorhersehbar zu sein. Ein Interessent testet einen Nachmittag, sieht den Call-Zähler steigen und kann nicht hochrechnen. Ein E-Mail-Sicherheitsunternehmen auf Freshdesk, das auf 20.000 Tickets pro Jahr zusteuert, verbrannte 200 API-Calls an einem einzigen Testtag und kam danach völlig besorgt darüber zurück, was 9.000 Interaktionen pro Monat mit der Zahl anstellen würden – nicht darüber, ob die Antworten gut waren. Ein anderer Betreiber, der auf 150.000 Tickets pro Monat zusteuerte, rechnete mit etwa 20 Cent pro Ticket, landete bei rund 30.000 $ pro Monat und blieb dort stecken.

Keines der beiden ist ein Token-Preis-Problem. Beides sind Einheiten-Probleme. Niemand plant in Millionen Token, und ein Pro-Token-Zähler macht aus jedem Kapazitätsgespräch eine Modellierungsübung statt einer Budgetzeile.

Das Gegenargument ist auch real, und ich zitiere es lieber, als darum herumzureden:

"We switched to a system that is working well at half the cost. But long term we will just build our own, which is so possible now with AI. I think you have a decent system for now, but we are probably too large of a customer for this."

Eine kanadische Marke für Waffenzubehör, die Zendesk mit 2.190 synchronisierten Dokumenten nutzt, aus eesels internen Sales-Call-Aufzeichnungen

Dieser Leser hat recht damit, dass die Modelle jetzt günstig genug sind, um den Eigenbau reizvoll zu machen, und Frameworks wie AgentKit haben auch das Scaffolding günstiger gemacht. Was die Token-Rechnung auslässt, ist Retrieval über Ihr Help Center, eine Helpdesk-Integration, die eine API-Änderung überlebt, Eskalationsregeln, eine Möglichkeit, gegen historische Tickets zu testen, bevor man es auf Kunden ansetzt, und jemanden, dessen Aufgabe es ist, das alles am Laufen zu halten. Wir haben erlebt, wie ein selbstsicher wirkender Bot in der Produktion falsche Antworten gegeben hat, weshalb jeder Rollout jetzt zuerst gegen echte vergangene Tickets simuliert wird, und Simulation ist kein Posten, den man auf einer Preistabelle kaufen kann.

Die ehrliche Version des Deals: Wenn Sie einen Klassifikator oder einen Summarizer brauchen, bauen Sie ihn auf der API und freuen Sie sich über eine Rechnung in Cent-Höhe. Wenn Sie etwas brauchen, das Kunden antwortet, kalkulieren Sie die KI-Agenten-Kosten end-to-end, einschließlich des Risikos von KI-Halluzinationen und der Wartung, die niemand einplant.

Vergleichen Sie das dann mit den Kosten pro Lösung bei etwas bereits Gebautem. Unsere Aufschlüsselung der Chatbot-Kosten rechnet dieselbe Arithmetik durch, und die Übersicht der KI-Helpdesk-Software deckt ab, womit Sie vergleichen würden.

Eine letzte praktische Anmerkung zur Governance, denn danach fragen die Leute nach ihrer ersten überraschenden Rechnung. Ausgabenobergrenzen liegen bei 500 $ auf Start, 1.000 $ auf Build und 200.000 $ auf Scale, wobei Custom die Obergrenze komplett entfernt. Stufen werden anhand der Nutzungshistorie zugewiesen statt gekauft, und neue Organisationen können in einer Evaluation-Stufe unterhalb der veröffentlichten Limits starten. Das Erreichen der Obergrenze pausiert die Nutzung bis zum nächsten Kalendermonat, was genauso funktioniert wie OpenAI-Rate-Limits, falls Sie die schon erlebt haben.

Die Nutzungsseite der Console zeigt Ihre Cache-Trefferrate direkt an, das ist die Zahl, die man sich zuerst ansehen sollte, und es lohnt sich, das mit LLM-Tracking-Tools richtig zu instrumentieren, wenn die Rechnung wichtig ist. Eine strukturelle Anmerkung für alle, die Routen vergleichen: Beim Enterprise-Plan kosten Sitzplätze 20 $ pro Monat zusätzlich zur Nutzung mit denselben API-Preisen, diese Preistabelle ist also die Enterprise-Nutzungsrechnung. Das ist eine andere Rechnung als bei Claude Pro, wo ein Pauschalabo die Nutzung stattdessen abdeckt.

eesel für Support-Automatisierung ausprobieren

Wenn der Grund, warum Sie die Anthropic API kalkulieren, eine Support-Queue ist, ist die Einheit das, was Sie vor dem Preis korrigieren sollten. eesel verlangt 0,40 $ pro Ticket ohne Sitzplätze und ohne Plattformgebühr, eine Zahl, die Sie in eine Prognose einsetzen können, ohne Token-Zahlen pro Konversation zu modellieren. Es lässt sich in wenigen Minuten in Zendesk, Freshdesk oder Gorgias einbinden, trainiert auf Ihrem bestehenden Help Center und vergangenen Tickets und simuliert gegen Ihre Tickethistorie, bevor es jemals einem Kunden antwortet, sodass Sie die prognostizierte Lösungsrate und die Kosten vor dem Go-Live sehen.

Sie bekommen trotzdem die Pro-Aktion-Sichtbarkeit, die Sie sich bei einem rohen API-Build selbst bauen müssten, was meist das Erste ist, was Teams beim Schätzen des Builds übersehen. Kostenlos zum Testen, und Sie sehen die prognostizierten Zahlen, bevor Sie sich auf irgendetwas festlegen.