GPT-6.1 Sol ist jetzt CodeRabbits Security-Engine — was das kostenlose Scan-Angebot im Wert von 1 Mio. $ wirklich bringt

CodeRabbit übernimmt bis zu 5.000 US-Dollar für KI-Sicherheitsprüfung pro Organisation, und das Zeitfenster endet am 8. November 2026 um 23:59:59 PST. Das Modell, über das es diese Arbeit abwickelt, ist GPT-6.1 Sol, das OpenAI am 29. September ausgeliefert hat — dies ist keine Launch-Story, und das Alter des Modells ist daran das am wenigsten Interessante. Was sich zwischen dem 23. und dem 26. Oktober geändert hat, ist enger gefasst und folgenreicher: Ein Code-Review-Unternehmen mit echter Reichweite in Unternehmen rückte dieses Modell ins Zentrum eines Sicherheitsprodukts, veröffentlichte den Workflow darum herum und setzte eine Frist für das Ausprobieren durch Fremde.

Drei Dokumente trafen innerhalb von vier Tagen ein. CodeRabbits eigener Blogbeitrag am 24. Oktober, eine OpenAI-Kundenstory am 26. Oktober und eine Business-Wire-Meldung am selben Tag, die sowohl die Zusage kostenloser Scans als auch CodeRabbits Aufnahme in das Daybreak Defense Network von OpenAI ankündigte. Zusammengelesen beschreiben sie ein Deployment-Muster, das es zu verstehen lohnt, selbst wenn Sie nie eines der beiden Produkte kaufen. Einzeln gelesen sind sie Marketing. Die nützliche Arbeit besteht darin, beides zu trennen.

Was CodeRabbit tatsächlich rund um GPT-6.1 Sol gebaut hat

Die OpenAI-Fallstudie ist sehr konkret, was die Platzierung angeht – und genau darauf kommt es an: GPT-6.1 Sol wird als Hauptmodell im Security-Agent von CodeRabbit beschrieben und arbeitet zusammen mit anderen Frontier-Modellen und den Scannern, die Kunden bereits einsetzen. Es wird nicht als Ersatz für statische Analyse dargestellt. CodeRabbits eigener Beitrag geht etwas weiter: Dort heißt es, CodeRabbit Secure verwende „GPT 6.1 Sol and GPT Cyber models“ – einen Stack, keinen einzelnen Aufruf.

Das Produkt hat drei Ebenen, und dabei handelt es sich wirklich um unterschiedliche Aufgaben:

• PR-Review — liest jede Änderung, sobald sie eingeht, direkt im normalen Review-Ablauf.

• Deep Scan — bildet das gesamte Repository ab statt nur eines einzelnen Diffs und verfolgt dabei, wie Komponenten und Abhängigkeiten zusammenspielen.

• CodeRabbit Secure — erweitert dies auf verknüpfte Repositorys, sodass eine Schwachstelle in einer gemeinsam genutzten Auth-Bibliothek ihren Wirkungsradius über jeden Dienst hinweg sichtbar macht, der sie importiert.

Die interessante Ingenieursarbeit liegt am Ende der Kette. Für Befunde, die ein Nutzer auswählt, versucht CodeRabbit, die Ausnutzbarkeit zu verifizieren, indem es den Befund in einer isolierten Sandbox ausführt – ausdrücklich nicht in der Produktion – und gibt einen von drei Zuständen zurück: Reproduziert, Nicht reproduziert oder Nicht eindeutig. Nur unterstützte Befunde werden zu einem vorgeschlagenen Fix, der als Pull Request geliefert wird, den ein Mensch prüft, testet und zusammenführt. Das Merge-Gate geht nie an das Modell über.

Diese Reihenfolge – zuerst Erreichbarkeit, dann Ausführung, dann Patch – ist der Grund, warum sich über dieses Deployment zu lesen lohnt. Die meisten Produkte der Kategorie „KI findet Bugs“ bleiben beim ersten Schritt stehen und geben Ihnen eine Liste, die nach der Konfidenz eines Sprachmodells sortiert ist. Eine Sandbox hinzuzufügen verwandelt eine Behauptung in einen Test. Einen Fix-PR hinzuzufügen verwandelt einen Test in einen Diff, den Ihre CI tatsächlich bewerten kann.

Das Angebot für den kostenlosen Scan, in den Bedingungen, die darüber entscheiden, ob Sie es nutzen können

Die Landingpage von CodeRabbit ist ungewöhnlich explizit, was die Mechanismen angeht, wodurch sich das Angebot leicht beurteilen lässt, statt nur mit zusammengekniffenen Augen darauf zu schauen:

• Zeitraum — 23. Oktober bis 8. November 2026, endet um 23:59:59 PST.

Obergrenze — bis zu 5.000 $ pro Organisation für Deep Scan-Nutzung und -Korrekturen.

• Gesamtpool — 1 Million US-Dollar, entnommen aus einem gemeinsamen Limit von 1.000.000 Credits, wer zuerst kommt, mahlt zuerst.

• Teilnahmeberechtigung — Organisationen mit zwei oder mehr Mitgliedern. Open-Source-Projekte, aktuelle Kunden, ehemalige Kunden und Teams, die CodeRabbit noch nie verwendet haben, sind alle berechtigt.

• Was umgewandelt wird — nur belegte Befunde werden zu Fixes, daher finanziert das Guthaben Untersuchung und Behebung, nicht das Versprechen, dass alles Gefundene gepatcht wird.

• Nicht genutztes Guthaben – beanspruchte, aber nicht ausgegebene Guthaben werden nach Ablauf der Frist oder nach Erschöpfung des gemeinsamen Pools nicht übertragen.

Diese Zeile zur Teilnahmeberechtigung sollte man zweimal lesen. „Any organization“ in der Pressemitteilung bedeutet jede Organisation mit mindestens zwei Mitgliedern, was Solo-Maintainer ausschließt – eine Gruppe, die einen großen Anteil des Open-Source-Codes verantwortet, von dem die meisten Unternehmen abhängen. Wenn Sie eine Einzelperson mit einem Repository sind, gilt das Angebot nicht für Sie, und daran ändern auch noch so viele Anmeldungen nichts.

Der zweite Punkt, der bei der Planung berücksichtigt werden muss, ist die Abrechnung. Deep Scan wird nach Nutzung abgerechnet, und repositoryübergreifender Kontext gehört zu dem, wofür Kosten anfallen; verknüpfte Repositories sind schreibgeschützt, was begrenzt, wie tief eine Untersuchung gehen kann, aber nicht, was ein Versuch kostet. Eine Obergrenze von 5.000 $ ist für ein mittelgroßes Monorepo großzügig und für ein großes nichts Besonderes, daher besteht der praktische Schritt darin, den ersten Scan auf das Repository zu richten, vor dem Ihnen am meisten graut, statt auf das, das am einfachsten zu übergeben ist.

Warum ein Modell mit einer Million Token die richtige Form für Repository-Arbeit ist

Die Spezifikation von GPT-6.1 Sol erklärt die Eignung besser als jeder Marketingtext. Sie verfügt über ein Kontextfenster von 1.050.000 Token mit bis zu 128.000 Token Ausgabe, akzeptiert Text- und Bildeingaben und unterstützt Batch, aber kein Fine-Tuning. Der Wissensstichtag ist der 30. April 2026. Fünf Reasoning-Einstellungen sind verfügbar — low, medium, high, xhigh und max —, wobei medium die Standardeinstellung ist und es keine Option „none“ oder „minimal“ gibt, um das Reasoning vollständig abzuschalten.

Die Preisgestaltung ist der Punkt, an dem die Struktur zur Strategie wird. Der Standard-Listenpreis beträgt 2 US-Dollar pro Million Input-Tokens und 10 US-Dollar pro Million Output-Tokens, wobei gecachter Input 0,10 US-Dollar und Cache-Schreibvorgänge 2,50 US-Dollar kosten. Anfragen mit mehr als 272.000 Tokens zahlen für die gesamte Anfrage das Doppelte für Input und Cache sowie das Eineinhalbfache für Output. Batch und Flex kosten 50 % von Standard; der Fast-Modus verdoppelt das; regionale Endpunkte kosten etwa 10 % mehr.

Liest man diese beiden Fakten zusammen, wirkt das CodeRabbit-Design nicht mehr willkürlich. Das Kostenprofil eines Security-Agenten ist kein Chat-Kostenprofil. Er liest enorme Mengen größtenteils unveränderten Quellcodes, erzeugt vergleichsweise wenig Ausgabe und profitiert mehr als fast jede andere Workload vom Prompt-Caching – ein Repository, das man wöchentlich scannt, ist ein Repository, dessen Kontext sich zwischen den Läufen kaum verändert. Bei $0.10 pro Million gecachter Eingabe-Tokens ist das erneute Lesen einer großen Codebasis auf eine Weise günstig, wie es das erneute Lesen bei $2 nicht ist. Der Zuschlagsschwellenwert von 272K ist die Zahl, auf die man achten sollte: Er liegt bei etwa einem Viertel des Fensters, was bedeutet, dass sehr große Scans den Multiplikator auf jedes Token in der Anfrage zahlen, nicht nur auf den Überschuss.

Wenn du das gegen dein eigenes Repository kalkulieren willst, gibt es GPT-6.1 Sol bei OrcaRouter zum Listenpreis – durchgereicht, 0 % Aufschlag, sodass die 2 $/10 $ und der Cache-Preis von 0,10 $ genau die Zahlen sind, die OpenAI veröffentlicht, und sich an dem Tag ändern, an dem OpenAI sie ändert. Das ist für diese Arbeitslast wichtiger als für Chat: Der gecachte Input erledigt den Großteil der Arbeit, und ein Prozentaufschlag darauf summiert sich über jeden Scan in einer Serie.

OpenAIs veröffentlichte Leistungskennzahlen für das Modell, die vom Anbieter angegeben und nicht unabhängig reproduziert wurden:

• DeepSWE v1.1 — 75,22 % bei hohem Aufwand, zu etwa 0,65 $ pro Aufgabe.

• Terminal-Bench Science 0.1 — 57,02 % bei maximalem Aufwand, zu etwa 5,47 $ pro Aufgabe.

• OSWorld 2.0 — 71,42 % bei maximalem Aufwand, zu etwa 1,27 US-Dollar pro Aufgabe.

• AutomationBench — 36,10 % bei maximalem Aufwand; GDP.pdf — 32,0 % bei hohem Aufwand.

{{1}}Faktenfehlerquote{{/1}} — 7,7 % bei geringem Aufwand, gegenüber 11,4 % für GPT-6 Sol, eine Verringerung, die OpenAI als relative Reduktion von etwa 32 % beschreibt.

Ein Detail in dieser Tabelle verdient mehr Aufmerksamkeit, als ihm zuteilwird: Bei DeepSWE erzielt „high effort“ 75,22 % und „max effort“ 71,90 %. Mehr Reasoning führte zu einem schlechteren Ergebnis. Wer standardmäßig die höchste Einstellung wählt, in der Annahme, sie sei durchweg besser, sollte sich dieses Paar ansehen, bevor er eine Security-Pipeline auf „max“ festlegt.

Die unabhängige Kennzahl, die die Erwartungen dämpfen sollte

Neun Tage vor der CodeRabbit-Ankündigung veröffentlichte Endor Labs eine Bewertung, die unmittelbar auf die Frage Bezug nimmt, die die Fallstudie offen lässt. Die Agent Security League des Unternehmens führte 200 Aufgaben mit Codex CLI 0.144.6 über die GPT-6-Familie hinweg aus und bewertete zwei Dinge: ob der Agent die Aufgabe überhaupt erledigte und ob er sie sicher erledigte.

GPT-6.1 Sol erreichte 77,7 % FuncPass und 34,1 % SecPass bei 179 bewerteten Aufgaben. GPT-6 Astra erzielte 82,1 % und 34,6 %. GPT-6 Sol erzielte 72,1 % und 25,1 %. Sols Verhältnis von SecPass zu FuncPass, 43,9 %, war das beste der vier getesteten Codex-Modelle – das heißt, es büßte die geringste Korrektheit ein, wenn Sicherheitsvorgaben angewendet wurden, obwohl seine absolute Sicherheitsbestehensquote um genau eine Aufgabe unter der von Astra liegt.

Dass zwei Drittel der Aufgaben an der Sicherheit scheitern, ist die Schlagzeile, und es ist ein echter Befund. Er ist zugleich keine Messung der Schwachstellenerkennung. SecPass fragt, ob ein Coding-Agent funktionierenden Code geschrieben hat, der zugleich sicher war – eine andere Frage als die, ob ein Sicherheitsagent Schwachstellen in Code findet, den jemand anderes geschrieben hat. 34,1 % als „GPT-6.1 Sol übersieht zwei Drittel der Schwachstellen“ zu lesen, wäre ein Kategorienfehler, und der Endor-Beitrag erhebt diesen Anspruch nicht. Was er stützt, ist ein engerer, schwierigerer Punkt: Bei Aufgaben, in denen Sicherheit und Funktionalität miteinander konkurrieren, opfern aktuelle Frontier-Modelle häufiger eines für das andere, als Anbieter suggerieren. Ein Sicherheitsprodukt, das auf diesen Modellen aufbaut, versteht man am besten als zusätzlichen Reviewer mit einem ungewöhnlichen Lesebudget, nicht als Orakel.

Die operativen Kennzahlen von Endor sind der nützliche Teil für alle, die das kalkulieren wollen. Median 7,9 Minuten pro Aufgabe, Mittelwert 13,5, neun Zeitüberschreitungen und ein vollständiger Durchlauf mit vier Workern, der in etwa 13 Stunden abgeschlossen ist. Der Token-Verbrauch lag bei rund 235 Millionen Input-Tokens bei etwa 94 % aus dem Cache, dazu 1,5 Millionen Output-Tokens – geschätzt 70 bis 85 US-Dollar zu Listenpreisen, gegenüber 104 US-Dollar für GPT-6 Sol und 468 US-Dollar für GPT-6 Astra. Endor meldete außerdem 13 Verdachtsfälle auf Cheating über fünf Signale und entlastete alle davon; bestätigte Fälle: null.

Was die Fallstudie Ihnen nicht verrät

Die Kundenstory von OpenAI enthält keine Falsch-Positiv-Rate, kein Erkennungsdelta gegenüber CodeRabbits Konfiguration vor Sol, keine Latenzwerte und keine Kosten pro Befund. Auch der Beitrag von CodeRabbit liefert diese nicht. Keiner von beiden ist dazu verpflichtet – eine Kundenstory ist keine Evaluation –, doch die Lücke bestimmt, wie viel Gewicht die Ankündigung tragen kann.

Die meistzitierte Statistik aus der Veröffentlichung erfordert die größte Sorgfalt. CodeRabbit meldet mehr als 8.000 Schwachstellen mit hohem oder kritischem Schweregrad, die in 30 Tagen bei 600 Organisationen gefunden wurden, wobei Broken Access Control, SQL-Injection und Authentifizierungsfehler über 70 % davon ausmachen. Das ist ein Aggregat für CodeRabbit Secure, kein Ergebnis von GPT-6.1 Sol, und nichts Veröffentlichtes führt irgendeinen Teil davon auf das Modell statt auf die Scanner und Menschen darum herum zurück.

Es gibt außerdem eine weit verbreitete Zahl, die falsch gelesen wird. Eine Sekundäranalyse dieses Deployments zitiert eine Ablehnungsrate von 56,3 % bei Vorschlägen aus einer Entwicklerumfrage von 2026 – ohne Anbieter, Stichprobengröße oder Methode der Umfrage zu nennen. Ablehnung ist nicht dasselbe wie ein Falschpositiv: Ein Entwickler kann einen korrekten Befund ablehnen, weil er außerhalb des Geltungsbereichs liegt, schlecht formuliert oder schlicht unbequem ist. Behandle 56,3 % als Beleg dafür, dass Review-Rauschen teuer ist, nicht als gemessene Falschpositivrate, denn niemand hat eine solche veröffentlicht.

Der dritte Vorbehalt betrifft speziell das Design. Weil die Sandbox „Inconclusive" als eigenständiges Ergebnis neben „Reproduced" und „Not reproduced" zurückgibt, wird ein Team, das zügig triagiert, lernen, diesen Eimer zu überspringen. Sobald das Überspringen zur Gewohnheit wird, werden Alerts in großem Stil stummgeschaltet – derselbe Fehlermodus, der Legacy-SAST-Tools leicht ignorierbar machte. Räumen Sie den unklaren Ergebnissen bewusst Aufmerksamkeit ein, sonst verkommt das Tool zu einer Compliance-Checkbox.

Nichts davon spricht dagegen, den kostenlosen Scan auszuführen. Es spricht dafür, ihn als Evaluierung mit einem Vorher-Nachher-Vergleich auszuführen, nicht als Ersatz. CodeRabbits eigene Darstellung positioniert Secure als Ergänzung zu bestehenden Tools, und das ist der richtige Standard: Behalten Sie Snyk, Semgrep oder CodeQL in der Pipeline und messen Sie, was die neue Schicht obendrauf hinzufügt, statt was sie über sich selbst sagt.

Das Gate, das niemand in die Pressemitteilung schreibt.

OpenAI stuft GPT-6.1 Sol als „kritisch im Bereich Cybersicherheit und hoch im biologischen/chemischen Bereich“ ein und regelt den Zugang über denselben Schutzmaßnahmen-Stack wie bei GPT-6 Astra, einschließlich Trusted Access und Daybreak. In der Praxis bedeutet das, dass cybersicherheitsfähige Nutzung mit Zugangsbeschränkungen belegt ist, und solche Beschränkungen erzeugen ihre eigenen Fehlalarme.

Es gibt einen dokumentierten Fall. Am 3. Oktober berichtete ein Entwickler im Community-Forum von OpenAI, dass eine schreibgeschützte, defensive AppSec-Pull-Request-Review im eigenen Repository rundheraus als eingeschränkter Cybersecurity-Inhalt blockiert wurde; die Antwort des Supports ordnete sie Daybreak Blue und Trusted Access for Cyber zu. Das ist ein einzelner Nutzerbericht gegenüber einer unbekannten Zahl erfolgreicher Anfragen, keine Messung – aber es ist der Fehlermodus, für den man planen muss. Wenn die Sicherheitsüberprüfung eine Produktionsabhängigkeit ist, gehen Sie davon aus, dass ein Teil legitimer defensiver Arbeit abgelehnt wird, und halten Sie einen Weg vor, der nicht über einen zugangsbeschränkten Endpoint führt.

Das Daybreak Defense Network ist die andere Hälfte dieser Struktur. Es ist OpenAIs Partnerprogramm, um Frontier-Cybermodelle in die Produkte und Dienste zugelassener Sicherheitsanbieter zu bringen statt direkt in die Hände der Kunden, verbunden mit Identitätsverifizierung, Tests mit definiertem Umfang, Protokollierung und menschlicher Aufsicht. Dass CodeRabbit beitritt und plant, OpenAIs spezielle GPT-Cybermodelle in CodeRabbit Secure einzubringen, ist ein bedeutenderes Signal als der Modellaustausch selbst: Es deutet darauf hin, dass der Stack für Sicherheitsüberprüfungen aufgeteilt wird, wobei ein allgemeines Reasoning-Modell die Breite abdeckt und zweckgebundene Cybermodelle die heikelsten Fälle übernehmen.

Das Muster, das es zu übernehmen lohnt – selbst wenn Sie beide Produkte überspringen

Entfernt man das Branding, ist das, was CodeRabbit veröffentlicht hat, eine dreistufige Schleife, die jedes Team zusammenbauen kann: dem Modell repositoryweiten Kontext einschließlich verknüpfter Abhängigkeiten geben, vermutete Befunde durch ausführungsbasierte Verifikation in einer isolierten Umgebung zwingen und einen überprüfbaren Diff ausgeben, den ein Mensch zusammenführt. Das Modell ist der am wenigsten proprietäre Teil. Die Sandbox und das Merge-Gate sind das, was die Ausgabe vertrauenswürdig macht, und beides liegt in Ihrer Kontrolle.

Das ist auch der günstigste Weg zu entscheiden, ob das kostenlose Angebot Ihre Zeit wert ist. Nehmen Sie ein Repository mit einer bekannten Schwachstelle, die Sie vor Monaten behoben haben, führen Sie den Scan aus und sehen Sie, ob er dieses Problem aufdeckt, wie lange er dauert und wie viel des Berichts für Sie tatsächlich handlungsrelevant wäre. Wenn er den eingeschleusten Fall findet und ansonsten still bleibt, lohnen sich die $5,000 vor dem 8. November. Wenn er eine Wand nicht eindeutiger Befunde zurückliefert, haben Sie das zum Preis eines Nachmittags gelernt.

Für Teams, die den Loop selbst bauen, statt ihn zu kaufen, liegt das operative Risiko in der Routing-Schicht. Ein unerprobtes Modell auf einen Produktions-Review-Pfad zu setzen, ist ein Glücksspiel, und automatisches Failover ist der Weg, es einzugehen, ohne die Pipeline zu verlieren, wenn die Leistung eines Anbieters nachlässt – die Anfrage geht an ein Fallback-Modell, statt dass der Job fehlschlägt. Derselbe Endpunkt bedient GPT-6.1 Sol und die Modelle, auf die Sie zurückfallen würden, sodass der Vergleich nur eine Parameteränderung kostet statt eines zweiten Vertrags und eines zweiten SDK.

Was man mit den nächsten zwölf Tagen anfangen sollte

Das Angebot ist kein Modellstart und sollte nicht als ein solcher bewertet werden. GPT-6.1 Sol ist seit dem 29. September abrufbar, und seine Benchmarks sind seitdem öffentlich; an seinen Fähigkeiten hat sich diese Woche nichts geändert. Geändert hat sich, dass ein Sicherheitsanbieter mit Unternehmensvertrieb sich öffentlich dazu bekannt, den Verifizierungs-Workflow dafür veröffentlicht und eine harte Frist für den kostenlosen Zugang gesetzt hat.

Wenn Sie ein Team mit zwei oder mehr Mitgliedern leiten und sich Sorgen um eine Codebasis machen, ist die Rechnung einfach: eine Obergrenze von 5.000 Dollar, ein Pool nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ und nach heute noch elf Tage Zeit. Buchen Sie den Scan jetzt für Ihr problematischstes Repository, pflanzen Sie einen bekannten Bug ein, wenn Sie eine Kontrolle wollen, und notieren Sie ebenso sorgfältig, was der Bericht falsch macht, wie das, was er richtig macht. Wenn Sie allein arbeiten oder Ihr Code bereits von Scannern abgedeckt ist, denen Sie vertrauen, dann ist die ehrliche Antwort, dass diese Ankündigung für Sie wenig ändert – das Modell war schon vor der Pressemitteilung verfügbar, und es wird auch nach dem Aufbrauchen der Credits verfügbar sein.