—mit Caching / Mo
—durch Caching gespeichert
—des verwendeten Kontextfensters
Kosten pro Sitzung, wenn Sie weitere Tools anschließen
Gleiche Umdrehungen pro Sitzung und gleiche Preise wie oben – nur die Anzahl der Werkzeuge ändert sich. Auf diese Weise kassieren Agenten, die der Einfachheit halber fünf oder sechs MCP-Server verbinden, in aller Stille eine Rechnung, die niemand bezahlen kann.
| Werkzeuge verbunden | Schema-Tokens | % des Kontexts | Kosten/Sitzung, kein Cache | Kosten/Sitzung, zwischengespeichert |
|---|
Woher die Zahlen oben kommen
Die erste Runde einer Sitzung zahlt immer den vollen Eingabepreis – es gibt noch nichts aus dem Cache zu lesen. Bei jeder weiteren Runde wird der identische Schemablock zum ermäßigten Preis aus dem Cache gelesen, solange sich nichts an der Werkzeugliste oder der vorherigen Eingabeaufforderung ändert.
Wie dies mit den anderen MCP- und Kontextkostenlinien zusammenhängt
Auf dieser Seite wird die wiederkehrende Token-Steuer für die Anbindung von MCP-Tools berechnet – es handelt sich nicht um die Kosten, die für den Betrieb des Servers dahinter anfallen. Preis auf dieser Seite, Hosting, Build und Wartung, auf der Kostenrechner für MCP-Server. Wenn Werkzeugschemata nur ein Teil dessen sind, was Ihr Kontextfenster überfüllt, ist die Kostenrechner für Kontextfenster Preise für das Gesamtbild einschließlich der abgerufenen Dokumente und des Gesprächsverlaufs. Die hier verwendete Caching-Mathematik – ein Lesevorgang zum vollen Preis, dann vergünstigte Lesevorgänge für den Rest der Sitzung – ist derselbe Mechanismus, der dahinter steckt Rechner für schnelle Caching-EinsparungenEs lohnt sich zu prüfen, ob Sie mehr als nur Werkzeugdefinitionen zwischenspeichern. Und wenn sich Ihre Tool-Schemata in einer größeren festen Systemeingabeaufforderung befinden, ist die System-Prompt-Kostenrechner Preise, die ganze Präambel, Werkzeuge inklusive, als eine einzige Steuer pro Anfrage.
So funktioniert dieser Rechner
Der MCP-Tool-Schema-Token-Kostenrechner vervielfacht Ihre Verbindung Werkzeuganzahl durch die durchschnittliche Token pro Toolschema Um das Gewicht des Tokens in den Kontext zu bringen, bevor ein Gespräch überhaupt beginnt, dividieren Sie es durch Ihr Gewicht Größe des Kontextfensters für den auffälligen Kontextprozentsatz. Ohne Zwischenspeicherung wird dieser Block erneut gesendet und in voller Höhe abgerechnet Eingangspreis Bei jeder Runde einer Sitzung betragen die nicht zwischengespeicherten monatlichen Kosten also Schema-Tokens × Runden × Sitzungen × 30 × Eingabepreis. Beim Prompt-Caching zahlt nur die erste Runde jeder Sitzung den vollen Preis; Jede weitere Runde liest den gleichen Block aus dem Cache, und das zum meist weitaus günstigeren Preis Cache-Lesepreis, sodass sich die Formel aus einem Lesevorgang zum vollen Preis plus Lesevorgängen minus einem Cachepreis ergibt, multipliziert über Sitzungen und Tage.
Das Ergebnis hängt vor allem davon ab, wie viele Tools angeschlossen sind und wie lange Sitzungen dauern. Eine Sitzung mit mehr Runden amortisiert die eine teure erste Runde gegenüber günstigeren zwischengespeicherten Lesevorgängen, weshalb der Prozentsatz der Caching-Einsparungen mit zunehmenden Runden pro Sitzung steigt und eine Single-Turn-Sitzung überhaupt keinen Nutzen aus dem Caching zieht – es gibt keinen wiederholten Lesevorgang mehr, der rabattiert werden könnte. Die Anzahl der Tools und die durchschnittliche Schemagröße wirken sich genauso stark auf die nicht zwischengespeicherte Seite aus, und sie beeinflussen die kontextkonsumierte Statistik unabhängig vom Caching, da ein zwischengespeicherter, aber immer noch vorhandener Schemablock immer noch den Kontext belegt, den das Modell bei jeder Runde lesen muss. Bei den Zahlen handelt es sich um ein transparentes Modell, das auf der von der Community gemeldeten durchschnittlichen Schemagröße von etwa 1.000 Token basiert, nicht auf einer Messung einer bestimmten Bereitstellung – die tatsächliche Schemagröße hängt davon ab, wie ausführlich die Parameterbeschreibungen der einzelnen Tools sind.