Was ist Cursor Origin? Die Git-Hosting-Plattform für KI-Agenten, erklärt

Cursor möchte Ihren Code nun hosten, nicht nur schreiben. Am 17. August 2026 begann das Unternehmen damit, Origin einzuführen, seinen eigenen Git-Hosting-Dienst, in einer frühen Beta-Phase für alle kostenpflichtigen Tarife. Repositories, Pull-Requests, Code-Browsing und die bidirektionale GitHub-Synchronisierung wurden am ersten Tag ausgeliefert, alles unter einem neuen Codebase-Tab im Editor.

Die Aussage ist unverblümt: Git-Schmieden wurden für Menschen konzipiert, die ein paar Mal am Tag Commits pushen. Cursor wettet darauf, dass das nächste Jahrzehnt der Versionskontrolle von Agenten geprägt wird, die rund um die Uhr Branches öffnen, PRs aktualisieren und Arbeiten zusammenführen. Origin ist die erste Hosting-Plattform, die von Anfang an auf dieser Annahme basiert.

Wenn Ihr Team APIs entwickelt, betrifft Sie dies früher, als Sie vielleicht denken: Ihre OpenAPI-Spezifikationen, Ihre CI-gesteuerten Vertragstests und Ihr Überprüfungsworkflow befinden sich alle dort, wohin Ihr Git-Remote zeigt. Hier erfahren Sie, was Origin heute leistet, was noch fehlt und wie Sie einen API-Workflow (einschließlich Apidog Testautomatisierung) intakt halten können, wenn Sie es ausprobieren.

Was Origin ist

Origin ist eine von Cursor betriebene Cloud-Git-Schmiede. Die anfängliche Beta-Version umfasst:

• Gehostete Repositories, die Sie über den Codebase-Tab, über das Web unter cursor.com/codebase oder von einem Cursor-Agenten während einer Aufgabe erstellen können. Remotes folgen dem Muster https://cursor.com/codebase/{owner}/{repo}, und standardmäßige git clone, push und pull Befehle funktionieren damit.
• Pull-Requests mit den erwarteten Bestandteilen: einer Zeitleiste, Commits, Prüfungen, Diffs, Kommentaren und dem Zusammenführen, überprüfbar im Editor oder im Browser.
• Code-Browsing und -Suche im Web, mit Einstellungen auf Repository- und Codebase-Ebene.
• Eine dedizierte CLI für Terminal-Workflows, getrennt vom Editor.
• Agentenintegration, was der eigentliche Punkt ist: Agenten können die Codebase lesen, Fragen dazu beantworten, Änderungen vornehmen, PRs aktualisieren und Branches von derselben Oberfläche pushen, auf der Sie ihre Arbeit überprüfen. Laut Changelog werden bald weitere „Agenten-native Funktionen“ ausgeliefert.

Verfügbarkeit: Nur für Pro-, Teams- und Enterprise-Pläne. Benutzer von kostenlosen Plänen können keine Origin-Repositories erstellen, und Enterprise-Organisationen können sich vollständig abmelden. Details wie Speicherkontingente, eine öffentliche API und Webhooks sind noch nicht dokumentiert, was Sie beachten sollten, bevor Sie etwas Wichtiges verschieben. Den aktuellen Stand finden Sie in den Origin-Dokumenten von Cursor.

Origin krönt einen ereignisreichen Monat für das Unternehmen; die Presseberichterstattung, einschließlich des Berichts von SiliconANGLE, weist auch darauf hin, dass die Einführung Tage nach dem Abschluss der Übernahme von Cursor durch SpaceX erfolgte. Für eine Auffrischung der Editor-Seite des Produkts behandelt unser Alles-was-Sie-wissen-müssen-Cursor-Leitfaden die Grundlagen.

Die GitHub-Synchronisierung ist der clevere Teil

Niemand migriert ein Unternehmen an einem Wochenende von GitHub, und Cursor weiß das. Daher setzt die Beta-Version von Origin auf eine bidirektionale Synchronisierung anstelle einer Migration:

• Spiegeln Sie ein GitHub-Repository in Origin, und synchronisierte Repositories aktualisieren sich in Echtzeit.
• PR-Kommentare und Reaktionen synchronisieren sich innerhalb von Sekunden in beide Richtungen: Ein in Cursor hinterlassener Kommentar wird auf GitHub veröffentlicht, und eine GitHub-Antwort erscheint in Cursor.
• GitHub bleibt die Quelle der Wahrheit für jedes Repository, das dort begonnen wurde. Pushes fließen weiterhin zu GitHub; Origin ist ein Live-Spiegel mit einer besseren Agentenfunktionalität, kein Ersatz-Remote.
• Zugriffsberechtigungen spiegeln Ihre GitHub-Lese-/Schreibberechtigungen wider, sodass die Synchronisierung nicht heimlich erweitert, wer ein Repository ändern kann.

Dies ist dasselbe Modell der unverbindlichen Einführung, das für Cursor gegenüber VS Code funktioniert hat: Niemanden zum Wechsel auffordern, sich neben dem etablierten System positionieren und den neuen Workflow durch Bequemlichkeit gewinnen lassen. Sie können die PR-Überprüfungs-Benutzeroberfläche von Origin am Montag ausprobieren, ohne Ihrem Plattform-Team Bescheid zu geben, da sich an Ihrem GitHub-Setup nichts ändert.

Der strategische Subtext ist schwerer zu ignorieren. GitHub ist seit fünfzehn Jahren die Standardheimat von Code, und seine eigene KI-Geschichte läuft über Copilot, das direkt mit Cursor konkurriert; wir haben die beiden in Cursor vs. GitHub Copilot verglichen. Dass Cursor seine eigene Schmiede aufbaut, ist eine Erklärung dafür, dass es seine Agenten-Roadmap nicht länger durch die Plattform eines Konkurrenten eingeschränkt sehen möchte.

Was fehlt (und das ist vorerst viel)

Die Beta ist eine Schmiede, keine vollständige DevOps-Plattform. Zum Zeitpunkt der Einführung hat Origin:

• Kein natives CI/CD. Stattdessen verbinden sich Depot und Buildkite über den Apps-Tab eines Repositories und können Ihre bestehenden GitHub Actions Workflow-Dateien gegen Origin-Repositories ausführen. Es ist eine pragmatische Brücke, aber es ist eine Drittanbieter-Abhängigkeit, wo GitHub ein integriertes Produkt hat.
• Keine Issues, keine Diskussionen, kein Wiki. Code-Reviews sind das einzige Kollaborations-Primitiv.
• Kein Self-Hosting, keine dokumentierte öffentliche API, keine Webhooks, keine angegebenen Speichergrenzen.
• Ein bemerkenswerter Launch-Partner: Verbinden Sie Vercel über den Apps-Tab, und jeder PR erhält eine Vorschau-Bereitstellung, die bei der Zusammenführung in Produktion geht, derselbe Workflow, den Vercel für GitHub-Repositories ausführt. (Vercel hat in letzter Zeit schnell ausgeliefert; es ist dasselbe Gateway, das derzeit den GPT-5.6 Sol Rabatt betreibt.)

Keine dieser Lücken spielt eine große Rolle, solange GitHub die Quelle der Wahrheit hinter der Synchronisierung bleibt. Sie werden enorm wichtig an dem Tag, an dem ein Team Origin als primär betrachtet. Behandeln Sie die Beta als eine Überprüfungs- und Agenten-Schicht, nicht als Infrastruktur.

Was dies speziell für API-Teams bedeutet

Ihr API-Workflow berührt die Schmiede wahrscheinlich an drei Stellen: Die Spezifikation befindet sich im Repository, Vertragstests laufen in CI bei jedem PR, und Reviewer genehmigen Änderungen an beidem. So wird jedes davon heute Origin zugeordnet.

Spezifikationen und Design-Review. Wenn Sie einem Design-First-Workflow folgen, ist Ihre OpenAPI-Datei das am häufigsten überprüfte Artefakt im Repository. Origins PR-Diffe behandeln YAML wie jeden anderen Text, und die bidirektionale Kommentar-Synchronisierung bedeutet, dass ein API-Reviewer, der in GitHub arbeitet, und ein Agenten-Operator, der in Cursor arbeitet, denselben Thread sehen. Nichts geht kaputt, und nichts verbessert sich bisher; der interessante Teil kommt, wenn Agenten beginnen, Spezifikationsänderungen als PRs vorzuschlagen, was genau der Kreislauf ist, für den Origin gebaut wurde. Unser Leitfaden zum Ausführen von Apidog CLI in Cursor behandelt bereits das Validieren einer Spezifikation durch den Agenten des Editors vor dem Commit.

CI-Vertragstests. Apidog CLI läuft als Schritt in jedem CI-System, und Origins Antwort auf CI ist „bringen Sie Ihre GitHub Actions Workflows über Depot oder Buildkite mit.“ In der Praxis bedeutet dies, dass ein bestehender Workflow-Schritt wie apidog run --scenario smoke-tests unverändert übernommen werden sollte, da das Workflow-Dateiformat dasselbe ist. Der ehrliche Hinweis: Wir haben Depots Actions-Kompatibilitätsebene diese Woche noch nicht gegen jede Aktion in freier Wildbahn überprüft, und niemand sonst hat dies getan. Führen Sie Ihre Pipeline gegen ein gespiegeltes Wegwerf-Repository aus, bevor Sie ihr einen Release-Branch anvertrauen.

Agentengesteuerte Änderungen benötigen agentensichere Gates. Die gesamte Prämisse von Origin ist, dass mehr Code von Agenten schneller ankommt. Das erhöht den Wert automatisierter, deterministischer Prüfungen bei jedem PR, da menschliche Reviewer zum Engpass werden. Eine Vertragstestsuite, die den Build fehlschlagen lässt, wenn ein Antwortschema abweicht, ist genau die Art von Gate, die mit dem Agenten-Durchsatz skaliert, und sie ist in Apidog in fünf Minuten eingerichtet: Definieren Sie Assertions einmal gegen Ihre Spezifikation, führen Sie sie über die CLI in der CI aus, die Ihre Origin-PRs ausführt. Laden Sie Apidog herunter, wenn Sie dieses Gate haben möchten, bevor Ihre Agenten Push-Zugriff erhalten, und sehen Sie sich unseren QA-Test mit Cursor-Leitfaden für den breiteren Test-Loop an.

Sollten Sie es ausprobieren?

Eine Entscheidungshilfe:

• Solo-Entwickler und kleine Teams mit kostenpflichtigen Cursor-Plänen: Ja, geringes Risiko. Spiegeln Sie ein Repository, nutzen Sie die PR-Ansicht, behalten Sie GitHub als Wahrheit bei. Sie verlieren nichts, wenn Origin sich nicht durchsetzt.
• Teams mit starker GitHub Actions-Investition: Probieren Sie es zuerst an einem Nebenprojekt aus. Ihre Workflows werden theoretisch über Depot oder Buildkite portiert, aber „theoretisch portiert“ ist kein Migrationsplan.
• Jeder, dessen Compliance-Anforderungen GitHub nennen: Warten Sie. Kein Self-Hosting, keine dokumentierte API und ein frühes Beta-Label machen Origin heute zu einem No-Go für regulierten Code.
• Teams, die bereits Cursor-Agenten intensiv nutzen: Dafür ist Origin da. Wenn Sie die Agentenfunktionen von Cursor täglich nutzen, ist es ein echter Workflow-Gewinn, wenn Agenten PRs in einer Schmiede öffnen und aktualisieren können, die sie als erstklassige Benutzer behandelt.

Die Schmiede wird zu einer Agenten-Oberfläche

Die eigentliche Geschichte ist nicht, dass GitHub einen neuen Konkurrenten hat. Es ist vielmehr, dass Cursor davon ausgeht, dass das Repository selbst primär zu einer Schnittstelle für Agenten wird, wobei Menschen die meisten Änderungen überprüfen und nicht selbst erstellen. Ob Origin gewinnt oder nicht, jede Schmiede wird in diese Richtung gezogen werden, und API-Teams werden es zuerst spüren, da Spezifikationen und Vertragstests die am stärksten automatisierbaren Überprüfungs-Gates in der Software sind.

Die Vorbereitung ist in beiden Fällen dieselbe: Machen Sie Ihre API-Checks skriptfähig und schmiedeunabhängig. Apidog hält Ihre Spezifikationen, Mocks und Testszenarien an einem Ort und führt sie über eine CLI aus, der es egal ist, ob der PR von einem Menschen auf GitHub oder einem Agenten auf Origin kam. Probieren Sie es kostenlos aus, und Ihre Überprüfungs-Gates bewegen sich mit Ihnen, egal wer den Schmiedekrieg gewinnt.

FAQ

Ist Cursor Origin kostenlos? Nein. Die Codespeicherung in Origin erfordert einen kostenpflichtigen Cursor-Plan (Pro, Teams oder Enterprise). Benutzer von kostenlosen Plänen können keine Origin-Repositories erstellen, und Enterprise-Organisationen können sich vollständig von Origin abmelden.

Muss ich GitHub verlassen, um es zu nutzen? Nein. Das Launch-Design geht davon aus, dass Sie dies nicht tun werden: Spiegeln Sie ein GitHub-Repository in Origin, und GitHub bleibt die Quelle der Wahrheit, wobei Pushes, PR-Kommentare und Reaktionen in nahezu Echtzeit in beide Richtungen synchronisiert werden.

Hat Origin CI/CD? Nicht nativ. Depot und Buildkite verbinden sich über den Apps-Tab und führen Ihre bestehenden GitHub Actions Workflow-Dateien aus. Vercel ist auch für PR-Vorschau-Deployments integriert.

Können Agenten Origin direkt nutzen? Ja, das ist die Kernfunktion: Cursor-Agenten können Repositories erstellen, Fragen zur Codebase beantworten, Pull-Requests aktualisieren und Branches pushen. Cursor sagt, dass weitere Agenten-native Funktionen kommen werden; unser Cursor Agentenmodus-Leitfaden behandelt, was Agenten bereits im Editor tun können.

Wie führe ich API-Tests für Origin-Pull-Requests aus? Auf die gleiche Weise wie auf GitHub: Führen Sie Apidog CLI als CI-Schritt aus. Auf Origin bedeutet das, Depot oder Buildkite mit dem Repository zu verbinden und Ihren bestehenden Actions-Workflow wiederzuverwenden, wobei Ihre `apidog run`-Befehle unverändert bleiben.