Grok 4.7 in Cursor und xAI API: Kostenberechnung, Effort-Modi, Fast-Modus und Kontext-Caching

Die Integration von Grok 4.7 (Modell-ID: grok-4.7) in Cursor hat unter Entwicklern großes Interesse geweckt. In der Benutzeroberfläche des Editors wurden neue Bedienelemente eingeführt: die Argumentationstiefe (reasoning_effort) sowie ein Umschalter für den Fast-Modus. Seit der Veröffentlichung herrscht jedoch Verwirrung um diese Einstellungen: Wie wirken sie sich auf den Verbrauch des Abonnement-Kontingents (Allowance) aus, und wie viele Anfragen werden bei typischen Entwicklungsaufgaben abgezogen?

Der zentrale methodische Fehler besteht darin, die Abrechnungsregeln von Cursor direkt aus den öffentlichen Tarifen der xAI-API ableiten zu wollen. Um fundierte Entscheidungen zu treffen, muss man zwischen zwei unabhängigen Ebenen unterscheiden: den offiziellen xAI-Preisen (einschließlich Kontext-Caching und der Schwelle für langen Kontext) und den internen Kontingentregeln von Cursor, die sich ausschließlich durch direkte Beobachtung im eigenen Konto verifizieren lassen.

---

Diskussion in der Community: Kontingent-Ungewissheit und fehlende Benchmarks

Die Diskussion über das neue Modell begann am 23. September in der r/cursor-Community infolge eines Beitrags des Nutzers IACROS, der das aktualisierte Modellauswahlmenü vorstellte.

In dem Thread wies der Nutzer diymuppet auf die Unklarheit bezüglich der Nutzungskosten hin:

„…es gibt keine genaue Vorstellung von den Allowance-Kosten… High / Extra High – was bedeutet das für mich persönlich?“

Das Community-Mitglied abjectchain96 riet von der Verwendung des Fast-Modus ab, vermutete doppelte Kosten und schlug vor, die Stufen des Reasoning-Efforts an der Komplexität der jeweiligen Aufgabe auszurichten.

Obwohl diese Empfehlungen plausibel klingen, lieferte die Diskussion keinen einzigen kontrollierten Benchmark oder verifizierten Kontoauszug des Cursor-Guthabens. Die Teilnehmer tauschten Vermutungen aus, ohne den tatsächlichen Kontingentabzug zu messen. Rückschlüsse auf den Kontingentverbrauch rein auf Basis von Spekulationen in Foren zu ziehen, ist unzuverlässig: Die Abrechnungsregeln werden durch die Abonnementbedingungen von Cursor bestimmt, nicht durch Schätzungen der Community.

---

Offizielle xAI-API-Preise: Kurzer vs. langer Kontext

In der öffentlichen API von xAI verfügt grok-4.7 über ein Kontextfenster von 500.000 Token und einen Wissensstand bis Mai 2026. Die Basistarife sind auf der offiziellen xAI-Preisseite veröffentlicht.

Standard-Kontext (< 200k Token)

Für Anfragen, bei denen das gesamte Eingabevolumen unter 200.000 Token bleibt, gelten die Standardtarife:

• Nicht zwischengespeicherte Eingabe (Uncached Input): $2.00 pro 1M Token
• Zwischengespeicherte Eingabe (Cached Input): $0.50 pro 1M Token
• Ausgabe-Token (einschließlich Reasoning): $6.00 pro 1M Token

Beispielrechnung für eine $0.27-Anfrage

Betrachten wir eine isolierte API-Anfrage mit folgenden Parametern:

• Nicht zwischengespeicherte Eingabe: 100.000 Token (Basiskontext, Systemanweisungen, Code der Aufgabe)
• Zwischengespeicherte Eingabe: 20.000 Token (unveränderter Verlauf der aktuellen Sitzung)
• Ausgabe-Token: 10.000 Token (Reasoning-Token plus generierte Antwort)

Schritt-für-Schritt-Aufschlüsselung:

1. Nicht zwischengespeicherte Eingabe: $100,000 \times \frac{$2.00}{1,000,000} = $0.20$
2. Zwischengespeicherte Eingabe: $20,000 \times \frac{$0.50}{1,000,000} = $0.01$
3. Ausgabe: $10,000 \times \frac{$6.00}{1,000,000} = $0.06$
4. Gesamtkosten der Anfrage: $$0.20 + $0.01 + $0.06 = \mathbf{$0.27}$

Schwelle für langen Kontext (≥ 200k Token)

Die xAI-API verwendet eine gestaffelte Preisstruktur: Sobald die gesamte Eingabe eines Prompts 200.000 Token erreicht oder überschreitet, gelten die erhöhten Tarife für alle Token dieser Anfrage und nicht nur für den darüber hinausgehenden Anteil.

Tarife für Kontext ≥ 200k:

• Nicht zwischengespeicherte Eingabe: $4.00 pro 1M Token
• Zwischengespeicherte Eingabe: $1.00 pro 1M Token
• Ausgabe-Token: $12.00 pro 1M Token

Konsistentes Beispiel für eine Anfrage ≥ 200k

Betrachten wir eine Anfrage in einer großen Codebasis, bei der der gesamte Eingabekontext die 200k-Schwelle überschreitet:

• Nicht zwischengespeicherte Eingabe: 180.000 Token
• Zwischengespeicherte Eingabe: 40.000 Token (gesamte Eingabe: $180,000 + 40,000 = 220,000$ Token ≥ 200k)
• Ausgabe-Token: 10.000 Token

Berechnung:

1. Nicht zwischengespeicherte Eingabe: $180,000 \times \frac{$4.00}{1,000,000} = $0.72$
2. Zwischengespeicherte Eingabe: $40,000 \times \frac{$1.00}{1,000,000} = $0.04$
3. Ausgabe: $10,000 \times \frac{$12.00}{1,000,000} = $0.12$
4. Gesamtkosten der Anfrage: $$0.72 + $0.04 + $0.12 = \mathbf{$0.88}$

Diese Schwelle gilt ausschließlich für direkte API-Aufrufe bei xAI. Die 200k-Schwelle lässt sich nicht auf die internen Abzüge in Cursor übertragen: Cursor verwaltet Kontextfenster und Tariflimits über eigene proprietäre Mechanismen.

---

Fast-Modus: Positionierung und Tarifspezifika

Der Fast-Modus wird häufig fälschlicherweise für eine leichtgewichtige Destillation gehalten. Gemäß den Spezifikationen von xAI gilt:

1. Architektur: Es handelt sich um das vollständige Modell grok-4.7, das auf einer optimierten Hochdurchsatz-Infrastruktur betrieben wird, um die Antwortlatenz zu minimieren.
2. Verfügbarkeit: Der Modus ist für Partnerintegrationen konzipiert (wie Cursor und die Grok-Build-Plattform) und wird nicht über die standardmäßigen öffentlichen Endpunkte von xAI angeboten.
3. Partnerpreise: xAI setzt für Partner im Fast-Modus Preise von $4.00 / $1.00 / $12.00 bei einem Kontext von < 200k an (exakt das Zweifache des Standards) sowie $6.00 / $1.50 / $18.00 bei einem Kontext von ≥ 200k (das 1,5-Fache der Standardtarife für langen Kontext).

Abzüge für den Fast-Modus in Cursor

Die Partner-Tarifstruktur von xAI bedeutet nicht, dass Cursor exakt zwei Anfragen abzieht oder den Allowance-Verbrauch verdoppelt. Das Abrechnungssystem von Cursor arbeitet mit eigenen Metriken (Fast Requests und Abonnementstufen). Die tatsächlichen Abzüge hängen von den Bedingungen Ihres Tarifs ab und können nur durch direkte Beobachtung des Kontostands überprüft werden.

---

Verwaltung von Reasoning Effort und Prompt-Caching

In Grok 4.7 ist der Denkprozess (Reasoning) nativ in die Modellarchitektur integriert und lässt sich nicht deaktivieren. Die Parameter presencePenalty, frequencyPenalty und stop werden nicht unterstützt und führen zu Anfragefehlern.

Der Parameter reasoning_effort steuert die Analysetiefe:

• low: Minimale Bedenkzeit und geringste Latenz; ideal für einfache Bearbeitungen und gezielte Tool-Aufrufe.
• medium: Ausgewogenes Verhältnis zwischen Generierungsgeschwindigkeit und Tiefe der Codesynthese.
• high (Standard): Gründliche Architekturanalyse, komplexe Abhängigkeiten und Algorithmen.
• xhigh: Maximale Suchtiefe, einhergehend mit einer spürbar höheren Latenz.

Die genaue Anzahl der internen Reasoning-Token ist in der öffentlichen Dokumentation nicht festgelegt; sie werden zu den regulären Ausgabe-Token-Tarifen abgerechnet. Man sollte weder annehmen, dass high für einfache Aufgaben nutzlos ist, noch dass xhigh für komplexen Code zwingend erforderlich wäre. Der einzig verlässliche Maßstab ist die Bewertung von Codequalität, Antwortlatenz und Kontingentverbrauch direkt anhand der eigenen Codebasis.

Funktionsweise des Prompt-Cachings

Der Mechanismus des Prompt-Cachings senkt die Kosten für wiederholt genutzten, unveränderlichen Kontext:

• Routing und Lokalität: Die Übergabe des Parameters prompt_cache_key in der Responses API oder des Headers x-grok-conv-id in Chat Completions leitet Anfragen gezielt an Knoten mit bereits aufgewärmtem Cache weiter. Dies erhöht die Trefferwahrscheinlichkeit im Cache, ist jedoch nicht zwingend erforderlich: Das Weglassen von Schlüsseln bedeutet nicht zwangsläufig, dass jeder nachfolgende Aufruf „kalt“ ist.
• Probabilistisches Caching: Cache-Treffer sind aufgrund möglicher Knotenneustarts oder Cache-Verdrängungen nicht garantiert. Das tatsächliche, vom Modell erkannte Cache-Volumen wird im Feld usage.prompt_tokens_details.cached_tokens zurückgegeben.
• Mehrstufiger Kontext: In mehrstufigen Dialogen (Multi-Turn) liefert die Responses API einen verschlüsselten Block reasoning.encrypted_content (oder Referenzen über previous_response_id) zurück. Die Übergabe dieses Blocks in Folgeanfragen erhält die Kette der Argumentation im Rahmen der unterstützten Spezifikation aufrecht. Dennoch sollte man nicht behaupten, dass der Cache in anderen Szenarien garantiert geleert wird oder der Kontext unwiederbringlich verloren geht.
• Präfix-Invarianz: Das Bearbeiten früherer Dialogschritte, das Ändern von System-Prompts oder das Umstellen von Kontextfragmenten zerstört das Cache-Präfix und reduziert die Trefferquote erheblich.

---

Gepaartes Benchmark-Protokoll: Messung des Cursor-Kontingents

Da der Abbau des Cursor-Kontingents nicht 1:1 den Dollarbeträgen der xAI-API oder der 200k-Schwelle entspricht, besteht die einzige Möglichkeit zur Ermittlung der tatsächlichen Kosten in einem isolierten Benchmark über zwei gleichwertige Aufgaben hinweg.

1. Vorbereitung (Setup)

• Bereiten Sie zwei Aufgaben von vergleichbarem Umfang und ähnlicher Komplexität innerhalb desselben Repositories vor (z. B. Task A und Task B: Erstellen von Testsuiten für vergleichbare Module).
• Öffnen Sie die Nutzungsübersicht Ihres Cursor-Kontos (Einstellungen unter Subscription / Usage).
• Erfassen Sie die Ausgangswerte anhand des folgenden Schemas:

Feld	Erfassungsbeispiel
Aufgabenkennung	Task A (Standard) / Task B (Fast)
Editor-Oberfläche	Chat / Composer
Modell und Modus	Grok 4.7 Standard / Grok 4.7 Fast
reasoning_effort-Stufe	medium (identisch für beide Tests)
Anfänglicher Kontingentstand	Erfassung vor dem Start
Generierungszeit (Latenz)	Gemessene Laufzeit (s)
Abschließender Kontingentstand	Erfassung nach der Antwort
Tatsächlicher Kontingentverbrauch	Differenz (abgezogene Einheiten / Anfragen)
Lösungsqualität	Korrektheit des Codes, bestandene Tests

2. Durchführung (Execution)

1. Test 1 (Standard): Starten Sie eine saubere Sitzung und wählen Sie Grok 4.7 im Standardmodus mit dem Level medium. Senden Sie Task A ab. Erfassen Sie die Generierungsdauer und notieren Sie den Kontingentabzug in Ihrem Kontoprofil.
2. Test 2 (Fast): Starten Sie eine neue, saubere Sitzung mit denselben Projektdateien und wählen Sie Grok 4.7 Fast mit dem Level medium. Senden Sie Task B ab. Erfassen Sie die Ausführungslatenz und den neuen Wert des Kontingentverbrauchs.

3. Entscheidungspfad (Decision Path)

• Wenn der Fast-Abzug dem Standard entspricht oder der Unterschied vernachlässigbar ist, bei spürbarem Geschwindigkeitsgewinn: Der Fast-Modus eignet sich hervorragend für interaktive Chats und schnelles Debugging.
• Wenn der Fast-Abzug wesentlich höher ausfällt und der Zeitgewinn zweitrangig ist (z. B. bei Hintergrund-Generierungen im Composer): Behalten Sie den Standardmodus als Standardeinstellung bei.
• Wenn die Codequalität bei medium unzureichend ist: Testen Sie high beim selben Aufgabentyp und beobachten Sie dabei die zusätzliche Latenz sowie den Kontingentverbrauch. Reservieren Sie high gezielt für komplexe Logik.

4. Fehlerbehebung und Diagnose (Troubleshooting)

• Das Kontingent verbraucht sich schneller als erwartet:
  • Überprüfen Sie die detaillierte Nutzungsaufschlüsselung im Cursor-Konto-Dashboard.
  • Prüfen Sie den aktiven Sitzungskontext: Lange Threads mit Dutzenden angehängten Dateien vergrößern den Prompt unabhängig von der Modellwahl erheblich.
  • Prüfen Sie die aktuellen Tarifregeln von Cursor. Vermeiden Sie die Annahme, dass die 200k-API-Schwelle von xAI die Abrechnung im Editor vorgibt.
• Verlängerte Antwortlatenz oder scheinbares Einfrieren:
  • Reduzieren Sie reasoning_effort auf medium oder low.
  • Starten Sie eine neue Unterhaltung, um die erneute Verarbeitung redundanter Historie zu vermeiden.
• Fehler bei der Modellverfügbarkeit:
  • Überprüfen Sie die Provider-Einstellungen und den Authentifizierungsstatus in Cursor.
  • Falls Sie einen eigenen API-Schlüssel verwenden, überprüfen Sie das Kontoguthaben und die Berechtigungen in der xAI-Entwicklerkonsole.

---

Quellen

1. xAI Docs — Grok 4.7
2. xAI Docs — Reasoning
3. xAI Docs — Prompt Caching in Multi-turn
4. xAI Docs — Pricing
5. Reddit r/cursor — Diskussion zu Grok 4.7