Cursors eigenentwickeltes Modell hat Opus 4.6 überholt, der Preis ist um ein Vielfaches gesunken, und die Atmosphäre im Bereich des Programmierens ist in Aufruhr geraten.
Was ist hier los, mein Freund!
Das neue Cursor-Modell übertrifft nicht nur Claude in der Leistung, sondern auch in der Preisgestaltung. Die Preise sind quasi auf die Hälfte des ursprünglichen Preises gefallen (eigentlich sogar noch weniger).
Es ist bekannt, dass Cursor als Modellanbieter in der Anfangsphase viele Fans gewann, indem es das Claude-Modell anbot.
Jetzt hat es jedoch sein eigenes Programmier-Modell entwickelt und Claude in den Schatten gestellt -
Sein neuestes Programmier-Modell Composer 2 übertrifft nicht nur Claude Opus 4.6 in der Leistung, sondern hat auch einen deutlich niedrigeren Preis.
Man kann es so sagen: Während andere Anbieter die Preise halbieren, schneidet Cursor die Preise quasi auf die Hälfte des halben Preises (also noch viel stärker).
Die Frage ist nun: Wie kann Cursor es schaffen, die Preise zu senken, während alle anderen Anbieter die Preise erhöhen?
(Hinweis: Mit der Popularität von "Lobster" hat der Token-Verbrauch von großen Modellen weltweit exponentiell zugenommen. Daher haben seit Anfang des Jahres Cloud-Anbieter und Anbieter von großen Modellen in- und ausländisch die Preise erhöht.)
Die Antwort wurde von Cursor ebenfalls bekannt gegeben -
Eine neue Methode des verstärkten Lernens.
Stärker als Opus 4.6 und der Preis geht immer weiter runter!
Zuerst einmal das bereits in Cursor verfügbare Composer 2.
Aus dem englischen Namen "Composer" (Übersetzung: "Arranger") kann man schon erahnen, dass dieses Modell auf die Programmierung abzielt (nicht aber auf die Musikarrangement).
Angesichts des starken Anstiegs des Token-Verbrauchs bei der Programmierung nach der Popularität von "Lobster" hat Cursor derzeit nur ein Ziel -
Kosteneffizienz, Kosteneffizienz und nochmal Kosteneffizienz.
Was ist Kosteneffizienz? Natürlich die optimale Kombination aus Intelligenz und Kosten.
In Bezug auf die Leistung sagt Cursor:
Composer 2 hat in allen von uns gemessenen Benchmarks signifikante Verbesserungen erzielt, darunter Terminal-Bench 2.0 und SWE-bench Multilingual.
Beispielsweise liegt seine Leistung bei Terminal-Bench 2.0, das die Fähigkeit von Agenten bei der Terminal-Bedienung misst, derzeit zwischen GPT-5.4 und Claude Opus 4.6.
Außerdem wird die Evolutionsgeschwindigkeit des Composer-Modells immer schneller.
In Bezug auf die Preisgestaltung beträgt der Eingabepreis für die Standardversion von Composer 2 0,5 US-Dollar pro Million Tokens (etwa 3,5 Yuan) und der Ausgabepreis 2,5 US-Dollar pro Million Tokens (etwa 17,2 Yuan).
Im Vergleich zu Claude Opus 4.6 ist der Preis fast auf das Niveau des "Knöchels" gesunken.
Zur gleichen Zeit hat Cursor eine "Variante mit gleicher Intelligenz, aber höherer Geschwindigkeit" - Composer 2 Fast - vorgestellt.
Der Preis für dieses Standardmodell beträgt 1,5 US-Dollar pro Million eingegebener Tokens (etwa 10,3 Yuan) und 7,5 US-Dollar pro Million ausgegebener Tokens (etwa 51,7 Yuan).
Im Vergleich zu Claude Opus 4.6 behält es nicht nur den Preisvorteil bei, sondern ist auch deutlich schneller.
Laut Cursor liegt der Schlüssel für das Gleichgewicht zwischen Leistung und Preis in der Einführung einer neuen Methode des verstärkten Lernens.
Wichtig zu beachten ist, dass es sich bei dieser Methode nicht um einen Inferenz-Trick handelt, sondern um eine tatsächlich trainierte Fähigkeit.
Einführung der Methode des verstärkten Lernens mit "Notizen machen"
Wenn man diese neue Methode in einem Satz zusammenfassen möchte, dann wäre es:
Das Modell lernt, "sich selbst Protokolle zu erstellen", um so lange und komplexe Aufgaben Schritt für Schritt zu bewältigen.
Die genauen Worte von Cursor lauten wie folgt:
Obwohl die Methode des "verstärkten Lernens durch Selbstzusammenfassung" etwas umständlich klingt, ist der Ansatz eigentlich sehr klar.
Das zentrale Problem, das sie löst, ist -
Heutzutage können die meisten AI-Programmier-Assistenten sehr gut arbeiten. Aber sobald die Aufgaben länger und komplexer werden, beginnen sie immer wieder zu scheitern.
Der Grund dafür ist bekannt: Der Kontext ist zu begrenzt.
Eine komplexe Softwareentwicklung kann leicht Tausende von Codezeilen und Hunderten von Schritten umfassen. Da das Kontext-Fenster eines Modells jedoch immer begrenzt ist, können viele Aufgaben nicht bis zum Ende durchgeführt werden.
Um die Kontext-Beschränkung zu überwinden, gibt es derzeit zwei gängige Lösungen im Bereich der "Komprimierung" in der Branche:
Entweder wird ein Zusammenfassung erstellt und dann fortgefahren, oder
das Kontext-Fenster wird einfach verschoben, um älteren Kontext zu verwerfen.
Oder es werden auch neuere Ansätze verfolgt - die Komprimierung im latenten Raum, bei der der Kontext in Vektoren anstatt in Text komprimiert wird (diese Methode ist zwar langsamer als die Textkomprimierung, aber genauer).
Aber alle diese Ansätze scheinen auf den ersten Blick nicht zuverlässig genug zu sein. Sie können dazu führen, dass das Modell wichtige Informationen im Kontext vergisst, was die Effektivität bei der Bearbeitung langlaufender Aufgaben verringert.
Mit anderen Worten: Je länger die Aufgabe, desto mehr neigt das Modell dazu, abzuweichen.
Die Lösung von Cursor besteht darin: Einerseits ist die Zusammenfassung wichtig, andererseits ist es auch wichtig, diese Zusammenfassungsfähigkeit in das Modell selbst zu integrieren.
Deshalb haben sie ihrem Modell einen "Self-Summary" (Selbstzusammenfassung) -Mechanismus hinzugefügt:
Wenn das Modell mittendrin ist, stoppt es nicht passiv, sondern aktiviert sich, um sich eine "Zwischenzusammenfassung" zu schreiben, also quasi "Notizen zu machen".
Der genaue Ablauf ist ungefähr wie folgt:
1. Composer erzeugt kontinuierlich basierend auf den Eingabewörtern, bis ein fester Token-Längengrenzwert erreicht wird. 2. Ein synthetische Abfrage wird eingefügt, die das Modell auffordert, den aktuellen Kontext zusammenzufassen. 3. Dem Modell wird ein gewisser Denkraum für Entwürfe gegeben, um die beste Zusammenfassung zu entwickeln, und dann wird der komprimierte Kontext erzeugt. 4. Composer kehrt mit dem komprimierten Kontext zu Schritt 1 zurück; dieser Kontext enthält die Zusammenfassung sowie den Dialogzustand (Planungszustand, verbleibende Aufgaben, Anzahl der vorherigen Zusammenfassungen usw.).
Ein wichtiger Punkt ist, dass die Selbstzusammenfassungsfähigkeit des Modells nicht ein Inferenz-Trick ist, sondern durch Training erworben wurde.
Im Prozess des verstärkten Lernens wird diese Zusammenfassungsfähigkeit in die Belohnung einbezogen:
Eine gute Zusammenfassung → höhere Wahrscheinlichkeit des Erfolgs bei späteren Aufgaben → höhere Belohnung
Eine Zusammenfassung mit fehlenden Informationen → Misserfolg der Aufgabe → Bestrafung
Als Ergebnis lernt das Modell langsam, welche Informationen beibehalten und welche verworfen werden können.
Der konkrete Effekt kann anhand des Vergleichs mit der herkömmlichen Methode gesehen werden.
Bei einer Reihe von schwierigen Softwareentwicklungsprojekten müssen bei der "herkömmlichen Zusammenfassungsmethode" Tausende von Tokens für die Zusammenfassungshinweise geschrieben werden, und das Ergebnis der Komprimierung ist auch nicht kurz, im Durchschnitt benötigt es 5.000+ Tokens.
Bei Composer ist die Hinweisphrase sehr einfach, im Wesentlichen nur der Satz "Please summarize the conversation", und die komprimierte Ausgabe beträgt im Durchschnitt nur 1.000 Tokens.
Bei den gleichen Aufgaben verwendet letztere nur ein Fünftel der Tokens der herkömmlichen Methode, und die durch die Komprimierung verursachten Fehler werden um etwa 50 % reduziert.
Mit anderen Worten: Die Komprimierung ist stärker, aber die Informationen sind wichtiger.
Was noch interessanter ist, kann es tatsächlich lange Aufgabenketten bewältigen.
Cursor hat ein klassisches Problem vorgelegt, das viele Modelle in die Enge getrieben hat - Das Doom-Spiel auf einer MIPS-Architektur ausführen.
Ich habe Ihnen /app/doomgeneric/ zur Verfügung gestellt, also den Quellcode von Doom. Ich habe auch eine spezielle doomgeneric_img.c geschrieben, die ich Ihnen empfehle zu verwenden; sie schreibt jeden gerenderten Frame in /tmp/frame.bmp. Schließlich habe ich auch vm.js zur Verfügung gestellt, das eine Datei namens doomgeneric_mips liest und ausführt. Der Rest sei Ihnen überlassen...
Da das Modell selbst den Code ändern, kompilieren, debuggen und wiederholt testen muss, bleiben viele Modelle später fast komplett stecken.
Aber Composer hat nach 170 Interaktionen die genaue Lösung gefunden und dabei 100.000+ Tokens auf 1.000 Tokens zusammengefasst.
Insgesamt zeigen eine Reihe von internen Tests:
Durch die Integration der Komprimierung in den Trainingszyklus hat Composer einen expliziten Mechanismus gelernt, der es ihm ermöglicht, wichtige Informationen effizient weiterzuleiten und bei schwierigen Aufgaben leistungsfähiger zu werden.
Wie bereits erwähnt, entwickelt Cursor sehr schnell. Nun haben die Cursor-Forscher auch Informationen über Composer 3 preisgegeben.