Technischer Kontext
Ich habe mich mit diesem Fall nicht als unbeteiligter Zuschauer befasst, sondern als jemand, der ständig AI integration in Arbeitswerkzeugen implementiert. Das Prinzip ist einfach: In Cursor kann man unter Settings → Models eine Custom-URL für einen OpenAI-kompatiblen Provider hinterlegen, den Key eingeben und das Überschreiben der Base-URL aktivieren. Auf dem Papier klingt das fast perfekt.
Doch dann kommt die Realität. Wenn Sie ein GPT-Abonnement oder einen Proxy zur Anfrageübersetzung durch Cursor schleusen wollen, stoßen Sie auf die API, die der Client tatsächlich anspricht. Laut Nutzerberichten und Dokumentationsanalysen läuft der benutzerdefinierte Pfad bei Cursor oft über /chat/completions, während neuere GPT-Szenarien teilweise bereits die Responses API erwarten.
Und an dieser Stelle würde ich keine Wunder versprechen. Bei standardmäßigen OpenAI-compatible Endpunkten funktioniert dies oft schnell. Für die neuesten GPT-Modelle oder Abonnement-Modelle benötigt man entweder einen sorgfältig konzipierten Proxy, der das Anfrageformat übersetzt, oder man muss damit leben, dass sich einige Funktionen fehlerhaft verhalten.
Ich verstehe vollkommen, warum man das überhaupt versucht. Nicht wegen der Benchmarks, sondern wegen der UX: Composer 2.5, Exploration, UI-Arbeit, schnelle Code-Korrekturen in einer einzigen Umgebung. In diesem Modus ist das build AI automation direkt in der IDE wirklich angenehmer, als ständig zwischen CLI und Web-Interface hin- und herzuspringen.
Beim Verbrauch des Composers habe ich ein wichtiges praktisches Signal aufgeschnappt: Bei einer neuen Codebasis verbraucht er in den ersten Tagen spürbar mehr, danach schaltet sich so etwas wie ein intelligentes Caching ein. In Diskussionen gab es einen Richtwert: Bei durchschnittlicher Nutzung waren nach zwei Wochen etwa 60 % verbraucht, wobei die ersten 30 % extrem schnell dahinschmolzen. Kein wissenschaftlicher Test, aber als Praxisorientierung sehr nützlich.
Was sich dadurch für Unternehmen und Automatisierung ändert
Kurz gesagt: Es gewinnen die Teams, denen die Denkgeschwindigkeit wichtiger ist als eine sterile Architektur. Cursor mit einem guten Modell beschleunigt die Code-Exploration, UI-Iterationen und kleinere Routineaufgaben in der Entwicklung enorm.
Es verlieren diejenigen, die hoffen, dass ein custom endpoint automatisch einen günstigen und nahtlosen Ersatz für die offizielle Integration bietet. Das wird nicht passieren, wenn die Protokolle nicht übereinstimmen. Eine falsche Kompatibilitätsschicht genügt, und der Agent verhält sich seltsam, während die Kosten ohne Nutzen steigen.
Ich würde hier zwei Wege vorschlagen: Entweder man konzipiert von Anfang an einen Proxy für das spezifische Anfrageformat, oder man lässt die Finger von diesem fragilen Setup dort, wo das Team eine verlässliche Production-UX benötigt. Wir bei Nahornyi AI Lab analysieren genau solche Engpässe: Wo eine AI implementation für das Team-Tempo sinnvoll ist und wo man besser eine solide Umgebung baut, damit automation with AI nicht zu einem teuren Experiment wird. Wenn Cursor, Ihre internen Tools oder Ihr Code-Agent bereits beginnen, Zeit und Budget zu verschlingen, lassen Sie uns Ihr Szenario prüfen und eine pragmatische Lösung entwickeln.