GPT-6.1 Sol are now live on CometAPI →
technology/CometAPI Research

Grok 4.7 API-Preise auf CometAPI: Offizielle Referenzwerte, Kostenschätzungen und Einsparungen

Vergleichen Sie die Grok 4.7-API-Preise mit den CometAPI-Preisen, schätzen Sie die monatlichen Ausgaben und senken Sie KI-App-Kosten durch Caching, Kontextsteuerung und Ausgabebegrenzungen auf Anwendungsebene.

CometAPI
Bobby SpencerForschungsteam für KI-Modelle und API
Aktualisiert Oct 1, 2026 11 Min. Lesezeit
Grok 4.7 API-Preise auf CometAPI: Offizielle Referenzwerte, Kostenschätzungen und Einsparungen
Dieses Muster verwenden

Den ersten API-Aufruf ausführen.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_COMETAPI_KEY",
    base_url="https://api.cometapi.com/v1",
)

response = client.chat.completions.create(
    model="gpt-5-mini",
    messages=[{"role": "user", "content": "Build this workflow."}],
)

print(response.choices[0].message.content)

xAI beschreibt Grok 4.7 als sein Spitzenmodell für Coding, Agentenaufgaben und Wissensarbeit mit einem Kontextfenster von 500K Tokens. Laut xAIs aktueller Preisseite betragen die direkten API-Preise unter 200.000 Prompt-Tokens $2.00 pro eine Million Eingabe-Tokens, $0.50 pro eine Million zwischengespeicherter Tokens und $6.00 pro eine Million Ausgabe-Tokens. Sobald ein Prompt 200.000 Tokens erreicht oder überschreitet, listet xAI entsprechend $4.00, $1.00 und $12.00. Dies sind xAI-Direktpreise, keine universellen Preise über Drittplattformen hinweg.

Die tatsächlichen Ausgaben hängen von mehr als dem Eingabe-Headline-Preis ab. Frische Eingaben, zwischengespeicherte Eingaben, Ausgaben, erneute Versuche, Tool-Aufrufe sowie die Anzahl der Modellaufrufe in einem Agenten-Workflow können die Rechnung verändern. Die 200K-Prompt-Schwelle ist besonders wichtig, da sowohl xAI als auch CometAPI höhere Langkontext-Preise veröffentlichen, sobald diese Grenze erreicht ist.

Dieser Leitfaden etabliert zunächst die xAI-Preisgrundlage und vergleicht dann das aktuelle CometAPI-Listing für Grok 4.7. Mit Stand vom 28. September 2026 listet CometAPI $1.60 / $0.40 / $4.80 pro eine Million frischer Eingabe-, zwischengespeicherter Eingabe- und Ausgabe-Tokens im Standard-Tarif und $3.20 / $0.80 / $9.60 im Langkontext-Tarif—20% unter den entsprechenden xAI-Direktpreisen. Die folgenden Abschnitte erklären, wie man die Arbeitslastkosten berechnet, Verschwendung reduziert und das Modell über CometAPI nutzt. Alle Preise sind Momentaufnahmen mit Datumsangabe und sollten vor dem Produktionseinsatz erneut geprüft werden.

xAI Direct vs. CometAPI Grok 4.7 Preise

xAI-Direktpreise (USD pro 1 Mio. Tokens)

TokenkategorieUnter 200K Prompt-TokensLangkontext (≥200K)
Frische Eingabe$2.00$4.00
Zwischengespeicherte Eingabe$0.50$1.00
Ausgabe$6.00$12.00

CometAPI-Preise (USD pro 1 Mio. Tokens)

TokenkategorieCometAPI: unter 200K Prompt-TokensCometAPI: Langkontext-Tarif
Frische Eingabe$1.60 / 1M Tokens$3.20 / 1M Tokens
Zwischengespeicherte Eingabe$0.40 / 1M Tokens$0.80 / 1M Tokens
Ausgabe$4.80 / 1M Tokens$9.60 / 1M Tokens

Die 200K-Prompt-Grenze ist relevant, weil beide Plattformen derzeit Langkontext-Tarife bei Grok 4.7 auf das Doppelte ihrer Standard-Tarife setzen. Das ist eine von jeder API-Plattform festgelegte Preisregel, keine Änderung der Modellfähigkeit. Eine Anfrage wird teurer, wenn eine Anwendung wiederholt große Prompts sendet oder Agentenverläufe unkontrolliert wachsen lässt—nicht einfach deshalb, weil Grok 4.7 ein 500K-Kontextfenster unterstützt.

Für die Budgetplanung sollten Sie jede Anfrage, die voraussichtlich die Grenze erreicht, als Langkontext behandeln, bis das aktive Abrechnungsverhalten verifiziert ist. Modellverfügbarkeit und Preise können sich ändern, daher sollten Produktionsrechner sowohl die xAI-Direktpreise als auch die aktuelle CometAPI-Modellseite erneut prüfen, anstatt permanente Werte hart zu codieren.

Die Formel zur Schätzung der Kosten für Grok 4.7

Schätzen Sie eine einzelne Anfrage, indem Sie jede Token-Kategorie separat bepreisen:

request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000

Wandeln Sie dann die Anfrage-Schätzung in eine Arbeitslastschätzung um:

monthly cost = request cost × requests per user × active users × days in billing period

Verwenden Sie ein realistisches Perzentil statt eines Durchschnitts. Eine p50-Schätzung beschreibt eine normale Anfrage, aber p95-Längen von Eingabe und Ausgabe offenbaren den teuren Ausreißer, der oft die Rechnung bestimmt. Für Agenten-Workflows multiplizieren Sie mit der erwarteten Anzahl der Modellaufrufe pro abgeschlossener Aufgabe. Ein Fünf-Schritte-Workflow sind fünf abrechnungsfähige Aufrufe, nicht einer.

Beispiel 1: Ein Support-Copilot

Nehmen wir an, eine Support-Anfrage sendet 6,000 frische Eingabe-Tokens und erzeugt 800 Ausgabe-Tokens. Sie bleibt unter der 200K-Grenze und erhält keinen Cache-Rabatt.

  • Eingabe: 6,000 × $1.60 ÷ 1,000,000 = $0.00960
  • Ausgabe: 800 × $4.80 ÷ 1,000,000 = $0.00384
  • Gesamt: $0.01344 pro Anfrage

Bei 100,000 Anfragen pro Monat betragen die geschätzten Tokenkosten $1,344. Wenn die Evaluation zeigt, dass eine 400-Token-Antwort genauso gut performt wie eine 800-Token-Antwort, sinkt die Schätzung auf $0.01152 pro Anfrage bzw. $1,152 pro Monat. Diese einzelne Ausgabeobergrenze spart rund $192 pro Monat bzw. 14.3%, ohne das Modell zu ändern.

Darum verdient die Output-Kontrolle Aufmerksamkeit. Zu den gelisteten CometAPI-Preisen kosten Ausgabe-Tokens dreimal so viel wie frische Eingabe-Tokens derselben Tarifstufe.

Beispiel 2: Wiederverwendung eines stabilen 20K-Token-Präfixes

Angenommen, jede Anfrage enthält ein 20,000-Token-Produktmanual, 2,000 Tokens neuen Gesprächskontext und eine 600-Token-Antwort.

Ohne Cache-Treffer lautet die Schätzung:

  • 22,000 frische Eingabe-Tokens: $0.03520
  • 600 Ausgabe-Tokens: $0.00288
  • Gesamt: $0.03808 pro Anfrage

Wenn das stabile Präfix mit 20,000 Tokens als zwischengespeicherte Eingabe abgerechnet wird und nur 2,000 Tokens frisch bleiben, ergibt sich:

  • 20,000 zwischengespeicherte Eingabe-Tokens: $0.00800
  • 2,000 frische Eingabe-Tokens: $0.00320
  • 600 Ausgabe-Tokens: $0.00288
  • Gesamt: $0.01408 pro Anfrage

Bei 100,000 Anfragen sind das $1,408 statt $3,808—eine geschätzte Ersparnis von $2,400 oder 63.0%. Die Ersparnis ist nicht automatisch: Die erste Anfrage, ein geändertes Präfix oder eine Route ohne Cache-Treffer kann weiterhin zum Preis für frische Eingaben abgerechnet werden. Bestätigen Sie die Anzahl zwischengespeicherter Tokens in den tatsächlichen Nutzungsdaten, bevor Sie die Schätzung als realisierte Einsparung behandeln.

Beispiel 3: Die Kosten des Überschreitens von 200K

Betrachten Sie eine langlaufende Agenten-Anfrage mit 210,000 Prompt-Tokens und 2,000 Ausgabe-Tokens. Unter Nutzung der gelisteten Langkontext-Preise:

  • 210,000 frische Eingabe-Tokens: $0.67200
  • 2,000 Ausgabe-Tokens: $0.01920
  • Gesamt: $0.69120 pro Lauf

Wenn Kontextkompaktierung, Retrieval-Filterung und Summary-Checkpoints den Prompt auf 180,000 Tokens reduzieren und dabei dieselben 2,000 Ausgabe-Tokens erhalten bleiben, lautet die Standardtarif-Schätzung:

  • 180,000 frische Eingabe-Tokens: $0.28800
  • 2,000 Ausgabe-Tokens: $0.00960
  • Gesamt: $0.29760 pro Lauf

Die Differenz beträgt $0.39360 pro Lauf oder etwa 56.9%. Über 10,000 Läufe ergibt sich eine geschätzte Ersparnis von $3,936. Die Lehre ist nicht, nützlichen Kontext zu löschen. Es geht darum, nur den Kontext zu behalten, der die Antwort verändert, und den Rest zu summarisieren oder zu retrieven, bevor die Anfrage eine Preisgrenze überschreitet.

Ein Python-Rechner für Vorab-Schätzungen

Die folgende Funktion verwendet die derzeit gelisteten Grok 4.7-Preise von CometAPI. Sie wendet vorsorglich den Langkontext-Tarif an, wenn der gesamte Prompt 200,000 Tokens erreicht.

from dataclasses import dataclass

@dataclass(frozen=True)
class Rates:
    input_per_million: float
    cached_input_per_million: float
    output_per_million: float

SHORT = Rates(1.60, 0.40, 4.80)
LONG = Rates(3.20, 0.80, 9.60)

def estimate_grok_47_cost(
    fresh_input_tokens: int,
    cached_input_tokens: int,
    max_output_tokens: int,
) -> float:
    prompt_tokens = fresh_input_tokens + cached_input_tokens
    rates = LONG if prompt_tokens >= 200_000 else SHORT

    return (
        fresh_input_tokens * rates.input_per_million
        + cached_input_tokens * rates.cached_input_per_million
        + max_output_tokens * rates.output_per_million
    ) / 1_000_000

estimate = estimate_grok_47_cost(
    fresh_input_tokens=2_000,
    cached_input_tokens=20_000,
    max_output_tokens=600,
)
print(f"Estimated upper bound: ${estimate:.5f}")

Dies ist ein Planungs-Schutzmechanismus, keine Rechnung. Die endgültigen Kosten hängen von tatsächlicher Eingabe, zwischengespeicherter Eingabe, Ausgabe, erneuten Versuchen, Tool-Aufrufen und dem aktiven Preis zum Ausführungszeitpunkt ab. Speichern Sie nach jeder Antwort die zurückgegebene Token-Nutzung, die Modell-ID, den Anfrage-Status und das Aufgabenresultat. Gleichen Sie diese Werte mit den Abrechnungsunterlagen des Anbieters ab.

Fünf Kostenhebel für Grok 4.7, nach voraussichtlicher Wirkung geordnet

1. Wiederholten Kontext stabil genug halten, um ihn zu cachen

Platzieren Sie statische Anweisungen, Produktdokumentation, Schemas und wiederverwendbare Beispiele vor inhalts- oder anfrage­spezifischem Content. Vermeiden Sie Änderungen an Zeitstempeln, IDs, Leerzeichen oder der Reihenfolge innerhalb eines großen gemeinsamen Präfixes, es sei denn, die Änderung ist erforderlich. xAIs Grok 4.7-Leitlinien empfehlen stabile Cache-Routing-IDs für Konversationen; bei Verwendung einer Zwischenroute prüfen Sie, welche Cache-Steuerungen und Nutzungsfelder unterstützt werden, bevor Sie sich darauf verlassen.

Messen Sie Cache-Treffer-Tokens und die Cache-Trefferquote nach Arbeitslast. Ein theoretischer Cache-Rabatt hat keinen Wert, wenn die Anwendung das Präfix ständig verändert.

2. Behandeln Sie 200K als Engineering-Budget, nicht als Ziel

Reservieren Sie Spielraum unterhalb der Schwelle für Systemanweisungen, abgerufene Passagen, Tool-Ergebnisse und den nächsten Benutzer-Turn. Kompaktieren Sie für Agenten alte Turns in eine validierte Zusammenfassung und bewahren Sie das Rohtranskript außerhalb des Modellkontexts auf. Beim Retrieval sollten Passagen gerankt und dedupliziert werden, bevor sie eingefügt werden, statt jeden Treffer zu senden.

Verfolgen Sie Prompt-Längenverteilungen und warnen Sie, bevor p95 die Schwelle erreicht. Nach dem offiziellen Tarifplan von xAI gilt: Sobald ein Prompt 200K Tokens erreicht, gelten Langkontext-Preise für alle Tokens in dieser Anfrage. CometAPI listet ebenfalls eine separate, höhere Langkontext-Stufe für Grok 4.7. Das sind Plattform-Preisbedingungen, keine Modellfähigkeiten.

3. Ausgabe begrenzen und den Reasoning-Aufwand gegen einen Evaluationssatz abstimmen

Setzen Sie eine an das Produkt angepasste, anwendungsweite Ausgabeobergrenze. Ein Klassifikationsergebnis benötigt womöglich Dutzende Tokens; eine Support-Antwort ein paar Hundert; ein Forschungsbericht mehr. Diese Obergrenze ist ein Budget- und UX-Kontrollinstrument, keine harte Grenze des Modells Grok 4.7. xAIs Release Notes vom 21. September besagen, dass Grok 4.7 keine Textausgabegrenze hat; das hindert eine Anwendung oder eine bestimmte API-Route nicht daran, eine eigene Anfragengrenze durchzusetzen. Bestätigen Sie jede endpoint- oder SDK-erzwungene Anfragengrenze mit der Route, die Sie tatsächlich nutzen.

Grok 4.7 unterstützt mehrere Reasoning-Aufwandsstufen. Verwenden Sie die niedrigste Stufe, die einen repräsentativen Evaluationssatz besteht, und reservieren Sie höheren Aufwand für Aufgaben, bei denen er eine messbare Verbesserung bringt. Das Reduzieren von Reasoning oder Output ohne Qualitätschecks kann zu erneuten Versuchen führen und die Ersparnis zunichte machen.

4. Teure Anfragen vor dem API-Aufruf ablehnen oder umformen

Schätzen Sie eine Obergrenze aus Eingabegröße und der konfigurierten Ausgabeobergrenze. Wenn die Anfrage das Produktbudget überschreitet, kann die Anwendung den Benutzer bitten, die Aufgabe einzugrenzen, hochgeladene Materialien zu summarisieren, den abgerufenen Kontext zu reduzieren oder den Job in einen genehmigten asynchronen Workflow zu verschieben. Das ist vorhersehbarer, als die Kosten erst nach der Generierung zu entdecken.

Eine grobe Zeichen-zu-Token-Approximation kann als früher Schutz nützlich sein, sollte aber einen Tokenizer oder tatsächliche Nutzungsdaten nicht ersetzen. Sprachen, Code, JSON und Formatierungen können sehr unterschiedliche Tokendichten erzeugen.

5. Kosten pro erfolgreicher Aufgabe optimieren, nicht Kosten pro Aufruf

Ein billigerer Aufruf, der zweimal durchfällt, kann mehr kosten als ein erfolgreicher Aufruf. Verfolgen Sie:

  • Kosten pro akzeptierter Antwort
  • Kosten pro abgeschlossener Agentenaufgabe
  • Kosten für erneute Versuche und Fallbacks
  • Cache-Trefferquote und Anteil zwischengespeicherter Tokens
  • p50- und p95-Prompt- und Ausgabe-Tokens
  • Qualitätswert, Latenz und Rate menschlicher Eskalationen

Wenn der Routineverkehr nicht die Qualität oder Kontextkapazität von Grok 4.7 benötigt, kann der einheitliche Modellkatalog von CometAPI einen anwendungsverwalteten Modellwechsel erleichtern. Halten Sie die Routing-Regel explizit, evaluieren Sie jedes Modell auf demselben Aufgabensatz und senden Sie nur die Anfragen, die von Grok 4.7 profitieren, an diese Route.

Eine praktische monatliche Kostenüberprüfung

Fassen Sie einmal pro Woche den Traffic nach Feature zusammen und vergleichen Sie die geschätzten Kosten mit der tatsächlichen Nutzung. Beginnen Sie mit den Features, die für die meisten Ausgabe-Tokens, die größten Prompts und die niedrigste Cache-Trefferquote verantwortlich sind. Überprüfen Sie dann teure Ausreißer, anstatt blind die Mediananfrage zu optimieren.

SignalWahrscheinliches ProblemErstmaßnahme
Niedriger Anteil zwischengespeicherter TokensGemeinsames Präfix ändert sich zu oftWiederverwendbaren Kontext stabilisieren und versionieren
Prompts clustern nahe 200KHistorie oder Retrieval ist unbegrenztKompaktieren, ranken und Spielraum reservieren
Ausgabe dominiert die AusgabenAntworten sind länger als das Produkt benötigtObergrenze senken und Antwortqualität testen
Hohe Kosten durch erneute VersucheValidierung, Timeouts oder Prompts sind instabilFehlerursache beim ersten Aufruf beheben
Niedrige Kosten, aber schlechte AufgabenerfüllungOptimierung hat nützliche Qualität reduziertKosten pro akzeptiertem Ergebnis messen

Rolle von CometAPI im Grok 4.7-Kostenmodell

Die Rolle von CometAPI in diesem Workflow liegt auf der API-Plattform-Ebene: Es bietet Zugriff auf Grok 4.7, veröffentlicht eigene Tokenpreise und dokumentiert einen OpenAI-kompatiblen Einstiegspunkt. Es ändert nicht die zugrunde liegenden Modellfähigkeiten von Grok 4.7. Teams, die bereits einen Client im OpenAI-Stil nutzen, können möglicherweise dasselbe Clientmuster beibehalten, während sie API-Schlüssel, Basis-URL und Modell-ID ändern, vorbehaltlich der Endpoint-Kompatibilität.

Mit Stand vom 28. September 2026 liegen die gelisteten Grok 4.7-Preise von CometAPI in Standard- und Langkontext-Tarif jeweils 20% unter den entsprechenden xAI-Direktpreisen. Dies ist ein Plattform-Preisvergleich, keine Aussage zur Modellqualität. Vor dem Produktions-Rollout sollten Teams außerdem die aktive Modell-ID, Endpoint-Parameter, Cache-Verhalten, Ratenlimits, Zuverlässigkeit, Support und Abrechnungsbedingungen verifizieren.

Zum Testen des Modells prüfen Sie die aktuellen Preise und Zugriffsdaten auf der CometAPI Grok 4.7-Modellseite. Halten Sie die Preistabelle in der Konfiguration, protokollieren Sie die tatsächliche Nutzung nach jedem Aufruf und führen Sie Arbeitslastschätzungen erneut aus, wann immer sich Modell- oder Produktverhalten ändern.

FAQ

Wie hoch ist der Preis pro Token für Grok 4.7 auf CometAPI?

Für Prompts unter 200K Tokens listet CometAPI derzeit $1.60 pro eine Million frischer Eingabe-Tokens, $0.40 pro eine Million zwischengespeicherter Eingabe-Tokens und $4.80 pro eine Million Ausgabe-Tokens. Die gelisteten Langkontext-Preise betragen entsprechend $3.20, $0.80 und $9.60 pro eine Million Tokens.

Wie viel kostet eine Grok 4.7-API-Anfrage?

Es hängt von frischer Eingabe, zwischengespeicherter Eingabe, Ausgabe und der aktiven Kontextstufe ab. Multiplizieren Sie jede Tokenanzahl mit ihrem Pro-Millionen-Satz, addieren Sie die Ergebnisse und teilen Sie durch eine Million. Berücksichtigen Sie außerdem erneute Versuche und jeden Modellaufruf in einem mehrstufigen Workflow.

Was ist der einfachste Weg, die Grok 4.7-API-Kosten zu reduzieren?

Beginnen Sie mit dem größten gemessenen Kostentreiber. Wiederholte lange Anweisungen profitieren in der Regel vom Caching; wachsende Agentenverläufe von Kompaktierung; ausführliche Antworten von einer niedrigeren Ausgabeobergrenze. Bestätigen Sie, dass die Qualität nach jeder Änderung akzeptabel bleibt.

Bedeutet ein 500K-Kontextfenster, dass ich 500K Tokens senden sollte?

Nein. Das Kontextfenster ist eine Kapazitätsgrenze, keine Empfehlung. Sowohl die xAI-Direktpreise als auch das aktuelle CometAPI-Listing verwenden höhere Langkontext-Preise an der 200K-Prompt-Schwelle, daher sollten Anwendungen nur den für die Aufgabe nötigen Kontext senden.

Kann ich die Kosten schätzen, bevor ich Grok 4.7 aufrufe?

Ja. Schätzen Sie Eingabe-Tokens, wählen Sie die richtige Kontextstufe, fügen Sie eine realistische Ausgabeobergrenze hinzu und berechnen Sie die Obergrenze. Ersetzen Sie nach dem Aufruf die Schätzung durch tatsächliche Nutzungsdaten für Reporting und Optimierung.

Weiterlernen

Diesen Artikel mit der nächsten Entscheidung verknüpfen.

Alle Themen anzeigen
Veröffentlicht am Oct 1, 2026
Zuletzt aktualisiert Oct 1, 2026
0 Aufrufe
Auf Klarheit, Quellenangabe und aktuelle API-Terminologie geprüft.

Mehr lesen