Cursor Models: Welche Modelle nach der Oktober-Umstellung passen

Geprüft am 25. Oktober 2026 anhand der aktuellen Dokumentation von Cursor zu Modellen, Abonnements, Router und Subagenten. Entscheidend ist der Unterschied zwischen einem verfügbaren Modell und enthaltener Nutzung: Das sind zwei verschiedene Zusagen.

Cursor Models: Welche Modelle stehen jetzt zur Verfügung?

Cursor unterstützt neben den eigenen Modellen Grok und Composer auch Claude, GPT und Gemini von Drittanbietern. Welche davon zugänglich sind, bestimmt das Abonnement. Im aktuellen Abosystem The X Subscription erhalten zahlende Konten ein wöchentliches Kontingent für Cursor-Modelle, das sie sich mit Grok teilen. Anfragen an Drittanbietermodelle werden aus vorausbezahltem Guthaben bezahlt. Die aktuelle Modellübersicht von Cursor beschreibt diese Aufteilung.

Die Tabelle unterscheidet aktuelle Abonnements von Bestandskonten mit älteren Tarifen. „Enthalten“ bedeutet, dass die Nutzung auf ein Kontingent angerechnet wird, nicht dass unbegrenzt viele Anfragen möglich sind. Free bietet begrenzte Nutzung; bei kostenpflichtigen Tarifen hängt das Kontingent vom Konto ab.

Quellen: verfügbare Modelle, aktuelle Abonnements und bisherige Tarife. Bei Teams und Enterprise fällt für bestimmte Drittanbieteranfragen zusätzlich die Cursor Token Rate an; die Liste der Ausnahmen ist dabei entscheidend. Einzelkonten zahlen diesen zusätzlichen Satz nicht.

Die monatlichen Preise für Einzeltarife vor Steuern betragen laut veröffentlichter Preisliste von Cursor Free $0, Plus $8, Premium $30, Super $100 und Ultra $200. Alle Preise sind in USD angegeben. Details zu Kontingenten, Teamlizenzen und älteren Tarifen stehen in der Übersicht der Cursor-Preise.

Welche Modelle bieten Free und Plus – und wo liegen die Grenzen?

Mit Free lassen sich die eigenen Modelle ausprobieren; Plus bietet eine eingeschränkte Programmierumgebung mit diesen Modellen. In Plus ist Fast ausgeschaltet und der Reasoning-Aufwand auf medium festgelegt. Grok 4.7 nutzt dort ein Kontextfenster von 256k. Auto, Drittanbietermodelle und eigene API-Schlüssel sind ausgeschlossen. Das sind ausdrückliche Tarifgrenzen. Wenn Claude in der Auswahl fehlt, muss also kein Installationsfehler vorliegen.

Für kleinere Änderungen mit Composer kann das ausreichen. Hängt der Arbeitsablauf hingegen ausdrücklich von Claude oder GPT ab, scheidet Plus bereits aus, bevor die Qualität der Ergebnisse überhaupt zur Debatte steht. Der benötigte Modellzugriff sollte daher vor dem Abschluss des Abonnements feststehen.

Was unterscheidet Premium von den bisherigen Tarifen?

Ab Premium sind Drittanbietermodelle verfügbar. Ein Nutzungskontingent dafür ist im neuen Abonnement jedoch nicht enthalten. Bei einem bestehenden Pro-, Pro+- oder älteren Ultra-Konto sieht es anders aus: Das monatliche Kontingent „Other Models“ deckt weiterhin Drittanbieternutzung zum API-Listenpreis des jeweiligen Modells ab. Ist es aufgebraucht, lässt sich weitere Nutzung über die aktivierte bedarfsabhängige Abrechnung bezahlen. Die Dokumentation zu den bisherigen Cursor-Tarifen erläutert den Unterschied.

Das neue Konto lässt sich mit einer Mitgliedschaft vergleichen, bei der das Hausmenü enthalten ist, Gerichte von Gastköchen aber separat berechnet werden. Ein Bestandskonto hat zusätzlich ein Kontingent für diese Gastgerichte. Derselbe Modellname kann deshalb in beiden Konten auftauchen, obwohl die Nutzung aus unterschiedlichen Guthaben bezahlt wird.

Vor einem Tarifwechsel sollten Bestandskunden ihre tatsächliche Drittanbieternutzung prüfen. Laut Cursor ist der Wechsel zum neuen Abonnement freiwillig und dauerhaft. Wer überwiegend Claude nutzt, kann ein enthaltenes Claude-Guthaben nicht durch ein größeres Kontingent für die eigenen Modelle ersetzen.

Welche Cursor-Modelle eignen sich für Routine und schwierige Aufgaben?

Die Modellwahl sollte sich daran orientieren, wo die Arbeit scheitert: an träger Interaktion, unvollständig erledigten längeren Aufgaben oder am benötigten Verhalten eines bestimmten Modells. Cursor empfiehlt in seiner Auswahlhilfe Composer für interaktives Programmieren, Grok 4.7 für die schwierigsten länger laufenden Aufgaben und Claude Opus oder GPT-5.6 Sol für komplexe Arbeiten mit mehreren Schritten. Die folgenden Beispiele übertragen diese Empfehlung auf den Entwicklungsalltag.

Composer 2.5: der Einstieg für Änderungen, die laufend begleitet werden. Laut Cursor ist das Modell auf Tool-Nutzung, Dateiänderungen und Terminaloperationen abgestimmt. Die Modellseite nennt ein Kontextfenster von 200k, eine schnelle Variante für interaktive Sitzungen und eine Standardvariante mit dem Schwerpunkt auf geringeren Token-Kosten.

Eine Änderung an einer Komponente mit einem klar fehlschlagenden Test ist eine passende Einstiegsaufgabe: die kleinstmögliche Korrektur anfordern, den Diff prüfen und im Austausch bleiben. Abbrechen sollte man, wenn wiederholte Korrekturen das eigentliche Problem nicht lösen. Dann braucht es eine bessere Aufgabenbeschreibung oder ein leistungsfähigeres Modell, statt ein unproduktives Gespräch immer weiterzuführen. Vor der Bewertung des Verbrauchsprofils sollte die Geschwindigkeitseinstellung geprüft werden: „Composer“ steht hier nicht für eine einzige feste Konfiguration.

Grok 4.7: für Aufgaben, die ausdauernde Untersuchung und Überprüfung brauchen. Nach Angaben von Cursor verbessert es gegenüber Grok 4.6 die Selbstüberprüfung und die Bearbeitung länger laufender Aufgaben. Eine Authentifizierungsänderung über mehrere Dateien hinweg ist ein typischer Fall, in dem Ausdauer zählt: Der Agent muss den Request-Handler, die Sitzungslogik, die Tests und die Fehlerpfade zusammen betrachten. Diese Prüfpunkte sollten vor der Übergabe der Aufgabe feststehen.

Die Dokumentation zu Grok 4.7 unterscheidet zwischen einem Standardkontext von 256k und einem Maximum von 500k. Gemessen wird in Tokens, also den Text- und Codeeinheiten, die ein Modell verarbeitet. Der Kontext bestimmt, wie viel Material das Modell in einer Anfrage berücksichtigen kann. Ein großes Fenster garantiert aber nicht, dass es die entscheidende Abhängigkeit erkennt. Deshalb gehören das fehlerhafte Verhalten und die Abnahmekriterien in die Aufgabe, nicht einfach nur mehr Dateien.

Grok 4.6 und Grok 4.5: beibehalten, wenn sich ein bestehender Arbeitsablauf damit bewährt. Cursor führt beide weiterhin auf. Die Seite zu Grok 4.6 empfiehlt jedoch 4.7 für bessere Selbstüberprüfung und längere Arbeiten. Für eine neue schwierige Aufgabe gibt es wenig Grund, aus bloßer Gewohnheit eine ältere Version als Standard zu wählen. Genauso wenig sinnvoll ist es, einen funktionierenden Ablauf umzustellen, ohne den Ersatz vorher zu prüfen. Der Vergleich von Grok 4.7 und Grok 4.6 behandelt diese Wechselentscheidung.

Claude Opus und GPT-5.6 Sol: gezielt für komplexe Arbeit oder einen anderen Lösungsansatz einsetzen. Ihr Nutzen zeigt sich dort, wo ein Problem von der anderen Interpretation eines Modells profitiert. Beim Wechsel sollten Aufgabe und Abnahmetests gleich bleiben. So lässt sich das Ergebnis beurteilen, statt nur die überzeugender formulierte Erklärung zu belohnen.

Die Cursor-Seite zu GPT-5.6 Sol beschreibt ausdauernde Agentenarbeit und knappe Antworten bei Planung und Fehlersuche. Sie nennt aber auch einen übermäßigen Einsatz von Subagenten sowie gelegentliches Warten auf eine ausdrückliche Aufforderung zur Umsetzung. Schlägt das Modell die richtige Korrektur vor und hält dann an, hilft eine klare Umsetzungsanweisung. Ein sauber formulierter Plan ist noch kein erledigtes Ticket.

Gemini: prüfen, wenn es bereits einen konkreten Grund für diese Wahl gibt. Cursor erwähnt in seiner allgemeinen Auswahlhilfe, dass manche Nutzer Gemini Pro bevorzugen. Das ist keine veröffentlichte Aussage darüber, dass Gemini eine bestimmte Programmierkategorie gewinnt. Der aktuelle Katalog enthält Gemini 4 Argon, Gemini 3.1 Pro und Gemini 3.8 Flash sowie neuere Claude-Einträge wie Opus 5.5 und Sonnet 5.5. Maßgeblich ist der Katalog der direkt auswählbaren Modelle, denn er ist vom Modellpool für Auto zu unterscheiden.

Als praktischer Standard bietet sich Composer für Arbeit an, die sich fortlaufend prüfen lässt. Grok 4.7 passt, wenn eine ausdauernde Untersuchung zum Engpass wird. Ein freigegebenes Drittanbietermodell ist sinnvoll, wenn seine Ergebnisse die gesondert berechnete Nutzung rechtfertigen. Für alle Modelle bleiben menschliche Prüfung und die Prüfungen im Repository der Maßstab für die Abnahme.

Cursor Auto: Was leisten Cost, Balance und Intelligence?

Auto wählt Modelle aus; es ist kein weiteres Modell. Der neuere Cursor Router setzt derzeit Teams oder Enterprise voraus. Die Router-Dokumentation von Cursor ordnet Balance und Intelligence diesem System zu. Plus schließt Auto ausdrücklich aus. Es ist daher nicht davon auszugehen, dass jedes Konto dasselbe Auto-Menü sieht.

Die Definitionen der Modi und die Abrechnungsregeln stammen aus der Router-Dokumentation von Cursor. Cursor beschreibt Balance als Standard für neue Nutzer; Teamadministratoren bestimmen jedoch, welche Modi angeboten werden. Der „empfohlene Einsatz“ ist die praktische Einordnung: Ein Routineticket beginnt mit der üblichen Einstellung. Aufwendigere Einstellungen sind dann sinnvoll, wenn die Aufgabe sie erfordert, nicht bloß aus Neugier.

Der derzeit dokumentierte Router-Pool umfasst GPT-5.5, Claude Opus 5, Grok 4.6 und Claude Fable 5. Cursor weist darauf hin, dass sich dieser Pool ändert und ein Modell bereits direkt auswählbar sein kann, bevor das Routing es einbezieht. Dass Grok 4.7 und GPT-5.6 Sol in der Modellauswahl stehen, belegt deshalb nicht, dass Auto Anfragen an sie weiterleitet. Als Referenz dient der veröffentlichte Modellpool.

Für Teamleitungen sind auch die Abhängigkeiten der Routing-Regeln relevant. Wird Grok 4.6 gesperrt, ist Router deaktiviert. Dasselbe gilt, wenn sowohl GPT-5.5 als auch Claude Opus 5 gesperrt sind. Nur eines der beiden letztgenannten Modelle zu sperren, verschlechtert laut Cursor die Routing-Qualität. Eine Freigabeliste sollte deshalb als funktionsfähige Routing-Konfiguration geprüft werden, nicht nur als Liste bevorzugter Anbieter.

Enterprise-Administratoren müssen Router aktivieren. Über die Teamsteuerung lassen sich Modi einschränken oder Auto vorschreiben. Die Administrationsoptionen erklären, warum sich eine Einstellung in einem Konto ändern lässt und in einem anderen nicht. Eine an ein Drittanbietermodell weitergeleitete Anfrage wird weiterhin nach dessen Regeln abgerechnet. Die Auswahl von Auto macht daraus keine enthaltene Nutzung eines eigenen Modells.

Wie lässt sich das Modell wechseln, ohne Einstellungen zu übersehen?

Das Modell wird im Chat- oder Agentenbereich gewechselt. Vor der nächsten Aufgabe sollten anschließend die Einstellungen geprüft werden. Laut Cursor bleibt die Auswahl über Gespräche hinweg erhalten. Das ist praktisch, bis die teure oder spezialisierte Wahl von gestern unbemerkt zum heutigen Standard wird. Die Anleitung zum Modellwechsel ist sowohl für ein bestimmtes Modell als auch für Auto der Ausgangspunkt.

Mehrere Modelle in Cursor: Wie wählen Subagenten ihr Modell?

Die Modellauswahl des Hauptagenten legt nicht das Modell jedes Subagenten fest. Ein Subagent ist ein eigenständiger Agent, dem ein Teil der Aufgabe übertragen wird. Die eingebauten Subagenten von Cursor wählen ein Modell passend zur Teilaufgabe. Benutzerdefinierte Subagenten verwenden standardmäßig inherit, übernehmen also das Modell des Hauptagenten, oder können eine Modell-ID vorgeben. Der Hauptagent kann beim Start eines Subagenten ebenfalls ein Modell angeben. Die Subagenten-Dokumentation von Cursor beschreibt diese Möglichkeiten.

Eine konkrete benutzerdefinierte Konfiguration kann in .cursor/agents/local-review.md liegen:

---
name: local-review
description: Reviews a bounded code change for correctness.
model: "composer-2.5[fast=false]"
---
Review the supplied diff and relevant tests.
Report concrete defects with file references. Do not edit files.

Die Modelleinstellung wählt ausdrücklich Composer 2.5 mit Standardgeschwindigkeit. Soll der Subagent dem Hauptagenten folgen, wird stattdessen model: inherit verwendet. Die Modellsyntax stammt aus der Konfigurationsreferenz von Cursor.

Die Folgen für die Abrechnung werden leicht übersehen. Ein Hauptagent mit Grok, Composer oder Auto kann eine Aufgabe an ein bestimmtes Drittanbietermodell delegieren. Dieser Subagent verbraucht im neuen Abonnement vorausbezahltes Guthaben und in einem älteren Tarif das Kontingent „Other Models“. Seine Aufgabenkarte zeigt das tatsächlich verwendete Modell; im Nutzungsdashboard wird dasselbe Modell erfasst. Tarifgrenzen und administrative Sperren können eine konfigurierte Auswahl außer Kraft setzen.

Bei einer unerwarteten Teamrechnung sind diese Subagentenprotokolle der richtige Ausgangspunkt. Dass der Hauptchat ein eigenes Modell angezeigt hat, bedeutet noch nicht, dass ein Kontingent falsch angerechnet wurde. Jeder Subagent hat einen eigenen Kontext und Token-Verbrauch. Delegation braucht deshalb einen sinnvollen Zweck: eine unabhängige Untersuchung, eine gesonderte Prüfung oder Arbeit, die von einem separaten Kontext profitiert.

Eigene Modelle in Cursor: Was ermöglicht ein API-Schlüssel?

Ein eigener API-Schlüssel ändert, wer die unterstützten Modellaufrufe abrechnet. Tarif-, Feature- und Anbietergrenzen hebt er nicht auf. Plus schließt BYOK aus, kurz für „bring your own key“, also die Nutzung eines eigenen Schlüssels. Laut Schlüsseldokumentation von Cursor werden OpenAI-Standard-Chatmodelle ohne Reasoning, Anthropic Claude, Google Gemini, Azure OpenAI und AWS Bedrock unterstützt, jeweils innerhalb der unterstützten Konfiguration des Anbieters.

Zum Einrichten unter Cursor Settings > Models den Anbieter auswählen, den Schlüssel eingeben und speichern. Bei geeigneten Einzeltarifen stellt der Anbieter diese Anfragen direkt in Rechnung. Sie verbrauchen weder das enthaltene Modellkontingent von Cursor noch dessen vorausbezahltes Guthaben. Bei Teams und Enterprise fällt für die betreffenden Anfragen weiterhin die Cursor Token Rate an. Die Tab-Vervollständigung nutzt weiterhin die eingebauten Modelle von Cursor.

Das ist sinnvoll, wenn eine Organisation bereits ein Anbieterkonto hat und die Modellnutzung darüber abrechnen möchte. Daraus folgt jedoch nicht, dass jede Modellvariante oder jedes Cursor-Feature dieses Konto nutzt. Bevor die Abrechnungsplanung eines Teams umgestellt wird, sollte geprüft werden, ob das konkrete Modell in der Auswahl erscheint und der benötigte Arbeitsablauf unterstützt wird.

Auch bei der Datenverarbeitung gibt es eine klare Grenze: Die Anfragen laufen weiterhin durch das Backend von Cursor, um die Prompts zusammenzustellen. Laut Cursor werden Schlüssel sicher übertragen und nicht dauerhaft gespeichert. Die Zero Data Retention-Richtlinie von Cursor gilt jedoch nicht für BYOK; maßgeblich ist die Richtlinie des Anbieters. Die Verbindung muss zu den Anforderungen der Organisation passen, nicht nur zur bevorzugten Rechnung.

Regionale Verfügbarkeit: Warum Modelle in der Auswahl fehlen können

Ein fehlendes Modell kann neben dem Tarif auch auf geografische Einschränkungen des Anbieters zurückgehen. Laut Cursor-Dokumentation zu Regionen können solche Einschränkungen Modelle aus der Auswahl entfernen. Als Ausweichmöglichkeit dienen ein anderes freigeschaltetes Modell oder Auto, sofern das Konto es anbietet. Ein Anbieterschlüssel funktioniert nur dort, wo der Anbieter den Zugriff erlaubt; eine regionale Sperre lässt sich damit nicht umgehen.

Ein verteiltes Entwicklungsteam sollte die geplante Konfiguration aus jeder beteiligten Region prüfen, bevor es einen Standard mit identischer Modellauswahl festlegt. Fehlt ein Modell, empfiehlt sich diese Reihenfolge: Tarif, administrative Freigabeliste, Verfügbarkeit beim Anbieter. Das ist eine hilfreichere Diagnose als wiederholtes Neuinstallieren des Editors.

Welche Schlüsse die Oktober-Umstellung nicht zulässt

Eine geänderte Tarifauswahl belegt nicht, dass GPT aus Cursor verschwunden ist. Zum Prüfdatum dokumentiert Cursor weiterhin GPT-5.6 Sol. Ein Beitrag in sozialen Medien reicht nicht aus, um den Ausstieg eines Anbieters oder einen Abschalttermin zu belegen. Für die aktuelle Arbeitsweise zählen der aktuelle Katalog und der tatsächliche Zugriff des eigenen Kontos.

Auto bedeutet auch nicht „jedes Mal das neueste Modell“. Sein validierter Modellpool unterscheidet sich vom Gesamtkatalog; seine Aufgabe ist die Auswahl passend zur jeweiligen Anfrage. Gehört ein bestimmtes Modell zu den Abnahmekriterien, sollte es nach Möglichkeit direkt ausgewählt werden, statt darauf zu hoffen, dass der Router es auswählt.

Ein größeres Kontextfenster oder ein höherer Reasoning-Aufwand ersetzt außerdem keine präzise Aufgabe. Bei einem schwierigen Fehler gehören die Reproduktionsschritte, das erwartete Verhalten und die Tests, die bestehen müssen in die Beschreibung. Mehr Kapazität schafft Platz für mehr Belege; fehlende Anforderungen kann sie nicht liefern.

Geht es um einen Modellzugriff über Anbieter, der sich in verschiedenen Coding-Clients nutzen lässt, behandelt der Vergleich der Cursor-Alternativen diese eigenständige Entscheidung. Der Wunsch nach einem solchen portablen Zugriff ist ein Grund, eine Ausweichlösung zu prüfen, ohne daraus abzuleiten, dass ein Anbieter Cursor verlassen hat.

Wer jetzt handeln, abwarten oder beim bisherigen Setup bleiben sollte

Entwickler sollten die Standardeinstellung erst ändern, wenn sie das damit gelöste Problem benennen können. Liefert Composer bei Routineaufgaben gut prüfbare Änderungen, kann es dabei bleiben. Brechen schwierige Aufgaben wiederholt vor dem Ziel ab, lohnt sich ein Test mit Grok 4.7 und einer klaren Abschlussbedingung. Liegt das Problem in einer unklaren Aufgabenbeschreibung, muss zuerst diese verbessert werden.

Teamleitungen sollten Routing und Subagenten jetzt prüfen. Dazu gehören die erlaubten Modelle, die sichtbaren Auto-Modi, die Anzeige des tatsächlich gewählten Modells und abweichende Modellvorgaben benutzerdefinierter Subagenten. Eine Richtlinie, die nur das Modell des Hauptagenten freigibt, lässt einen Teil des tatsächlichen Ablaufs ungeprüft.

Wer Claude, GPT oder Gemini benötigt, sollte Plus ausschließen. Bestandskunden sollten mit dem Tarifwechsel warten, bis klar ist, welches Kontingent sie verlieren würden. Ein funktionierendes Konto mit älterem Tarif muss die neue Abrechnungsstruktur nicht übernehmen, nur weil sich die öffentlich angebotenen Tarifnamen geändert haben.

Für Montag bietet sich ein einfacher Praxistest an: ein gewöhnliches und ein schwieriges Ticket aus dem eigenen Backlog auswählen. Das gewählte Modell, seine Einstellungen, die Modelle der Subagenten, die abgeschlossenen Prüfungen und den Verbrauch festhalten. Bewährt ist das Setup, das akzeptable Ergebnisse mit möglichst wenigen Korrekturen und vorhersehbarem Verbrauch liefert. Diese Beobachtungen sind nützlicher, als das ganze Team allein auf einen Modellnamen zu vereinheitlichen.

Häufige Fragen

Der Newsletter liefert praxisnahe Anleitungen zu Modelländerungen und den Arbeitsabläufen, die sie betreffen.