AI-bedrijf Cursor brengt GitHub-concurrent Origin uit

AI-programmeertool Cursor komt met een concurrent voor GitHub. Het platform gaat Cursor Origin heten en is bedoeld om code op te hosten. Betalende gebruikers krijgen als eerste toegang tot een bèta van het platform.

Cursor bevestigt de komst van Origin in een blogpost. De bèta van het codeplatform wordt vanaf nu uitgerold naar gebruikers met een abonnement, aldus het bedrijf. De dienst ondersteunt volgens Cursor de essentiële Git-onderdelen, zoals repository's, pullrequests en het bekijken van code.

De dienst kan bovendien gesynchroniseerd worden met bestaande GitHub-repo's, aldus de AI-start-up. Gebruikers kunnen hun GitHub-account koppelen en hun repository's automatisch kopiëren naar Origin. De synchronisatie verloopt automatisch: veranderingen op GitHub worden overgezet naar Origin en andersom.

Verder zegt Cursor dat Origin een focus krijgt op AI. Op termijn moet het platform bijvoorbeeld 'agent-native' functies krijgen voor het gebruik van AI-agents. Wat die features precies inhouden en wanneer ze verschijnen, is niet duidelijk. Ook zegt Cursor niet wanneer Origin voor alle gebruikers beschikbaar komt.

Cursor als AI-bedrijf

Cursor bestaat sinds 2022. Het bedrijf is vooral bekend van zijn Code Editor, zijn ide-software voor het schrijven van code. Dat programma legt sterk de nadruk op AI en heeft allerlei AI-functies om code mee te schrijven en te beoordelen.

In juni werd bekend dat Cursor overgenomen zou worden door SpaceX, het ruimtevaart- en AI-bedrijf van Elon Musk. Sinds deze maand is Cursor officieel onderdeel van dat bedrijf. Daarmee introduceert Cursor zijn eerste product sinds de overname.

Een repository in Cursor Origin. Bron: Cursor

Reacties (122)

[Toelly]

De kans dat de gehoste code gebruikt zal worden voor het trainen van AI lijkt mij groot.

[Dannydekr]

Alsof dat bij GitHub niet het geval is.

[Toelly]

Klopt, maar dat is ook een moeilijk punt voor veel developers die momenteel op github hosten. Een alternatief zoals https://codeberg.org/, die expliciet claimen dit niet te doen, is dan interessanter.

[applesap]

op codeberg heb je wel geen private repositories dus een AI bedrijf kan gewoon eender welke repo clonen om erop te trainen

[teek2]

Ik heb daar wel private repo's, maar idd, er staat dat ze dat niet doen. Dat is wel vreemd.

[Powerblast]

Volgens de terms of use in principe beperkt in omvang en voor zaken die je niet publiek wil, maar ondersteunend voor andere publieke repos vermoed ik. Hoe actief ze daar echt in sturen weet ik niet.

[StefanJanssen]

op codeberg heb je wel geen private repositories

wel geen? Op codeberg heb ik gewoon toegang tot het maken van private repos

[Reactie gewijzigd door StefanJanssen op 19 augustus 2026 13:43]

[maali]

ze hebben wel private, maar met beperkte ruimte (150MB per repo dacht ik dat het was)

[Powerblast]

Dat vind ik er ook een beetje het vervelende aan. Ze doen het zelf niet, maar alle AI scrapers halen het er wel gewoon af. Ik zou persoonlijk eigenlijk een manier willen waarbij ik code publiek kan delen met de beperking dat AI het in zijn geheel niet mag gebruiken. Maar dat bestaat vrees ik niet. license in principe maar welke AI bot kijkt daar nog naar…

[faxityy]

Codeberg is dan wel weer heel erg anti-AI minded, of tenminste het leiderschap en vooral de betalende vocale leden (die LLM als plagiaat zien) zijn dat. Er was een paar weken geleden wat ophef publiekelijk, waarna ze discussies of stemmingen rondom AI gebruik snel achter semi-gesloten deuren gebracht hebben voor de betalende/donerende leden.

https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage

Bij puntje 7;
_{You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as Claude, OpenAI Codex).}
Dit vind ik gevaarlijk vaag en specifiek, en valt toe te passen wanneer men er zin in heeft. Voor mij een veel te geopinioneerde regel en ongeacht je voor of tegen AI bent. Als men zo expliciet gaat opleggen dat ik bepaalde code niet mag pushen naar hun platform, waar stopt het toevoegen van uiterst specifieke terms dan.

Meer leesvoer voor de interesseerde: https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html

[nlinzweden]

Er zijn jarenlange rechtzaken gevoerd over hergebruik van code. Volgens de standaarden van 4 jaar geleden breekt het de wet.

[Barsonax]

Tja maar het is ook plagiaat, die modellen zijn immers getraind op allerlei opensource code maar men houdt zich niet aan de licenties.

Vroeger mocht dit echt niet en nu accepteren we het soort van maar het is eigenlijk een hele rare situatie.

En dan heb je ook nog bepaalde mensen die roepen dat alle engineers vervangen kunnen worden door AI. Snap wel dat die engineers pissed zijn want ze worden gewoon genaaid waar ze bij staan.

[r2504]

Gitlab zou het niet doen (en heeft private repo's).

[MichaelBelgium]

Bij github kan je kiezen,in privacy settings

Allow GitHub to use my data for AI model training

Allow GitHub to collect and use my Inputs, Outputs, and associated context to train and improve AI models. Read more in the Privacy Statement.

[Reactie gewijzigd door MichaelBelgium op 19 augustus 2026 16:29]

[Luchtbakker]

De kans dat de gehoste code gebruikt zal worden voor het trainen van AI lijkt mij groot.

Want OpenAI, Antropics, Meta en dat soort bedrijven doen dat al niet veel langer met alles wat op github staat?

[jesse!]

Nee, die hebben geen toegang tot jouw private repositories.

[divvid]

uhuhuhuh. dat vraag ik mij af. Ik had ooit problemen met code voor een voor mij nieuw framework (vrij onderwerp specifiek ding). ChatGPT suggereerde een functie die niet werkte. Inspectie van de framework code was duidelijk, de functie bestaat niet. De ontwikkelaar zit een paar deuren verderop, dus ff gevraagd. Was ooit een experimentje in zijn eigen private repo.

Blijkbaar toch gelekt naar het model. Of dat per ongeluk toch ergens in een publieke branch heeft gezeten is niet meer te achterhalen. De hele repo is naar een interne gitlab verhuisd en die branches zijn opgeschoond.

Maar kan ook goed zijn dat private repo's ook gewoon gescanned worden.

[jesse!]

Snap je reactie, maar die code heeft op veel meer plekken dan die private git repo gestaan. Waaronder waarschijnlijk ook in zijn eigen AI / claude code / copilot oid..

[divvid]

hem kennende gebruikt hij dat niet.

[Mellow Jack]

Dan is wel de vraag of het een logische functie is of niet. Stel je hebt CRUD operaties waarbij de D (Delete) nooit is geïmplementeerd. Vrijwel elk model zal erop gokken dat de functie wel bestaat. Het is namelijk logisch om die te hebben.

[divvid]

klopt, de functie op zich was logisch, maar uiteindelijk op een andere manier geimplementeerd, en niet via die specifieke functie.

[Concept8]

Dan is het dus een logischere verklaring dat de LLM de functie prima zelfstandig erbij kan hallucineren. Dat is ook het hele punt van hallucineren, toch? Geen onderdeel van de trainingsdata maar toch als antwoord gegeven omdat het een hoge waarschijnlijkheid heeft.

[divvid]

en wat is de waarschijnlijkheid dat een lmm een behoorlijk obscure naam verzint die exact gelijk is aan wat een developer in een private repo maakt? Occams razor-->private repo's worden ook gescraped door github (sorry configuratie 'foutje')

[Jerie]

Third party scraping kun je afdwingen. Bij first party scraping is die incentive er niet.

De hamvraag is dus of je niet beter af bent bij Codeberg of Gitlab.

[Ananas_hoi]

Liever gitlab, ook een grote partij met redelijke kwaliteit maar zij hebben de privacy van hun klant tenminste wel hoog in het vaandel. Zeker bij zelfhost bestaat dat risico nieteens meer.

[witi77]

Bij zelfhost zou ik sneller Gitea of Forgejo pakken of je moet een grote club zijn. GitLab is best fors. Ik draai nu zelf een paar maanden op Forgejo en het is echt heerlijk om zelf Git te draaien.

[teek2]

Ik ben toch voor GitLab gegaan en het is idd een monster, maar werkt verder (na wat gedoe met Caddy as rev proxy) erg goed. Ik vrees wel soms een beetje voor de community edition als ik dit soort dingen lees: https://techcrunch.com/2026/06/03/gitlab-cuts-14-of-staff-as-it-scales-its-platform-to-serve-ai-workloads/

[duvekot]

Gitea is wat mij betreft ook een no-go .. zeker nu Forgejo lekker door ontwikkeldt. Bij Gitea gaat er toch een "Chinese invloed" meespelen.

[isog]

Kan het zijn dat je Gitee bedoeld?

[duvekot]

Nee...Gitea Ltd (die de eigenaar is van de domeinen en alle code) is geregistreerd in Hong Kong ..

[Moortn]

Zal ongetwijfeld afhankelijk zijn van je account of subscription. Als bedrijf wil je dat uiteraard niet, voor een hobby project zie ik weinig problemen.

Ik gebruik nu (privé) ook AI-providers die de prompts en data gebruiken om de trainen. Er staan toch geen credentials, URL's of anderszins gevoelige data in.

[com2,1ghz]

Bij ieder ander partij waar jij data hebt staan is het een kwestie van het wijzigen van de algemene voorwaarden waarbij jouw data wordt gebruikt voor hun financieel belang.

En zelfs dan heb je geen garantie want een partij koopt gewoon het bedrijf inclusief de gegevens op en kan dan aan de slag met de data.

[YGDRASSIL]

Er is een setting waarmee je dit kan instellen....

Cursor’s current Terms of Service state that Anysphere will not use your content to train AI models, or allow third parties to do so, unless you explicitly agree to it.

The important distinction is Privacy Mode:

• Privacy Mode ON: repository/code data is not used for training by Cursor, and Cursor says its model providers will not train on it either.
• Privacy Mode OFF: Cursor says it may use codebase data, prompts, code snippets, and editor activity

[Ananas_hoi]

Ergens wel slim gekozen naam: in git is de standaardnaam van de eerste server (remote) die je aan een map toevoegt ook origin.

Een versiereferentie heeft die servernaam ook altijd als prefix:

origin/stable, origin/v1.2.3, origin/HEAD.

Dus die naam komt overal terug. Zou git-scm, de ontwikkelaar van git, nu ook een wijziging van de standaardnaam overwegen, zoals in de geschiedenis vergelijkbaar gedaan is met de oude “master” standaarbranch? (Die nu standaard “main” heet vanwege slaaf-meester associaties?)

[SirQuack]

Ik denk dat als het heikele punt in de term "origin" (ofwel bron) zou zitten, dit ten tijde van het EA-platform Origin al zou zijn aangepast.

"master" naar "main" omdopen was natuurlijk niet alleen in Git een wijziging, maar op allerlei plekken (zoals bijvoorbeeld in python of de Linux kernel).

[Ananas_hoi]

Je hebt gelijk: de master->main verandering is deel van een grotere trend en dit is niet vergelijkbaar.

Maar je EA origin vergelijking gaat ook niet helemaal op - dat heeft niets met software ontwikkelen te maken. Straks deel je die bron-aanduiding met de naam van een bedrijf in dezelfde sector.

Wellicht zijn er nog wel meer termen die gedeeld worden met bedrijven, maar de grote jongens die ik uit m’n hoofd ken zijn allemaal “origineel”:

GitHub, GitLab, BitBucket, Gitea… _{Wellicht mis ik er nog een paar}

[StefanJanssen]

zoals in de geschiedenis vergelijkbaar gedaan is met de oude “master” standaarbranch? (Die nu standaard “main” heet vanwege slaaf-meester associaties?)

Ah ja, de beslissing waarvan de voorstanders in de mailing allemaal witte mensen waren en de tegenstanders een aantal zwarte mensen had. De reden? Master heeft in de git context nul relatie met meester-slaaf relatie.

Ik ben groot voorstander van discriminatie uit de (tech)wereld te halen, maar zoals de tegenstanders van de wijziging in git aangaven: Dit haalt de aandacht weg bij dingen die daadwerkelijk zin hebben.

Deze wijziging heeft in mijn ogen meer kwaad gedaan dan het goed deed. Men zegt namelijk meerdere dingen met deze wijziging:
1) De naamgeving beslissing die we in de vroege jaren gedaan hebben was fout.
2) Het heeft de "anti-woke" groep meer ammunitie gegeven
3) Wij weten het beter dan de mensen waarover wij zeggen dat dit probleem over gaat.

Het is alsof de mensen die een skatepark voor rolstoel gebruikers ontwerpen, misschien van 1 of 2 rolstoel gebruikers input vraagt en dan volkomen negeert. Je kunt niet de groep mensen waar je het over hebt niet uitsluiten van het gesprek. Uit angst om niet te discrimineren doet men dingen die discriminerend zijn.

Was deze verandering gedaan vanuit met als argument "main is een iets minder abstract begrip dan master" of iets dergelijks was de verandering in mijn ogen beter te accepteren geweest.

Ik ben ook erg blij dat we niet de "master studies" hebben hernoemd voor dezelfde redenen als hierboven beschreven, en ben ergens verrast dat deze discussie eigenlijk niet gevoerd is destijds.

[FPSUsername]

Ik denk dat we in elektro wereld in ieder geval nog lang niet afscheid gaan nemen tussen mannelijke en vrouwelijke connectoren en crimp terminals. En ja, je kunt "transgender connectoren" maken door te mixen en matchen. Of er nou een naamwijziging op moet komen.. Het is nu (nog) in ieder geval duidelijk wat wat is.

[Mars Warrior]

Ik ben ook erg blij dat we niet de "master studies" hebben hernoemd voor dezelfde redenen als hierboven beschreven, en ben ergens verrast dat deze discussie eigenlijk niet gevoerd is destijds.

Dat zou wat zijn ja, maar net als Git waren er nooit "slave" versies hiervan toch? Geen slave branch, geen "slave studies".

In veel gevallen betekent "master" niets meer dan "origineel" of "bron". Dus master key, master tape, master stamp. Oftewel het origineel waar je elke keer een kopie van maakt omdat vaak het maken van een kopie van een kopie van een kopie nogal eens misgaat

In Github is het natuurlijk een non-issue: je kunt nog steeds je master branch "master" noemen ipv "main". Vond ik wel fijn destijds: alles bleef daardoor werken namelijk.

[redbullzuiper]

Ook de ontwetendheid dat slaaf niet gelijk staat aan "zwarte mens" maar dat er altijd slaven van alle kleuren zijn geweest. Ze reduceren het woord slaaf tot een "slavernijverleden van paar honderd jaar geleden".

Grappig dat ik ze ook nooit gehoord hebt over "master en slave replication" wat nog steeds voorkomt als term, dat heeft meer met meester en slaaf te maken dan het woord master in git ooit heeft gehad.

[StefanJanssen]

Ook de ontwetendheid dat slaaf niet gelijk staat aan "zwarte mens" maar dat er altijd slaven van alle kleuren zijn geweest.

Dat klopt inderdaad, nu is het wel zo dat er vandaag de dag minder opmerkingen die slaaf gerelateerd zijn in de richting van witte of asiatische mensen dan naar zwarte mensen en dat is ook de reden dat het rasistisch is. Ondanks dat er een paar jaar geleden ergens in Nederland een fruit teler mensen als slaaf behandelden, ik meen dat het toen om arbeiders uit Bulgarije ging.

Als iemand morgen een minderheid uitscheld voor "blebo" is dat geen racisme, maar dat dit uiteindelijk zo uitgroeit dat deze minderheid dat regelmatig uitgemaakt wordt voor "blebo" is dat wel racisme.

Het gaat dus niet zozeer om de daadwerkelijke betekenis van het woord maar hoe men het gebruikt.

[ComputerGekkie]

git-scm heeft toch ook geen heroverweging van de naam genomen omdat we Git[hub/lab/ea/forge] hebben?

[Luctia]

Nou is GitHub bepaald niet perfect, maar de kern is in ieder geval gemaakt voordat AI de kop op stak. Naast dat GitHub al langer draait en zich op die manier "bewezen" heeft, vermoed ik dat er tijdens de ontwikkeling van Origin flink van AI gebruik zal zijn gemaakt en hoewel dat tegenwoordig een stuk beter werkt dan vroeger, heb ik er niet genoeg vertrouwen in om dat de plek te maken waar de backup en geschiedenis van al mijn code staat.

[Reactie gewijzigd door Luctia op 19 augustus 2026 14:47]

[Ananas_hoi]

Sinds de opkomst van agentic AI is de kwaliteit van GitHub ook enorm achteruit gegaan.

Zie bijvoorbeeld deze pagina: https://mrshu.github.io/github-statuses/

[Wraldpyk]

Dat is niet sinds Agentic AI, dat is sinds Github in de Microsoft organisatie is ondergebracht in het AI deel van Microsoft. GitHub is nu alleen maar een afdeling binnen Microsoft AI, kort gezegd.

[t1mmy]

Op dit punt denk niet dat het ene gecentraliseerde systeem vervangen door een andere zo'n goed idee is, blijf je gewoon het zelfde gezeur houden. En het is van Musk.

[SirQuack]

Git is niet verplicht gebonden aan een remote, en zodra je eenmaal de repository hebt gecloned kan je switchen naar welke omgeving je maar wil.

Je kan dus prima je code op zowel Cursor Origin, Microsoft GitHub, GitLab, Codeberg en je eigen Gitea insteance hebben staan, en dan ergens een procesjes hebben wat ze met elkaar up-to-date houdt (of gewoon 5 remotes in je lokale Git repository hebben).

Is dit wenselijk? Lijkt me sterk, maar het kan wel.

[Zerora]

Ik zou er nog niet eens een "Hello World"-app uploaden nu het bedrijf van Elon Musk is.

[GeroldM]

Omdat Musk's Grok er dan automatisch: "Heil world" ervan maakt?

[svane]

Handig (voor Musk en co dan).....

Nadat Grok Build betrapt is op het doorsluizen van hele repositories, kunnen ze die data gewoon op deze manier krijgen.

xAI's Grok Build coding CLI was uploading entire Git repositories, full commit history and all, to a Google Cloud Storage bucket run by xAI, not just the files a coding task needed.

A researcher publishing as cereblab, testing version 0.2.93, captured one of those uploads, cloned the git bundle out of the intercepted request, and pulled back a file the agent had been told in plain terms not to open.

Als ik iemand niet vertrouw met code of gevoelige data is het deze partij wel, snel links laten liggen.

[Zarhrezz]

Grootste probleem bij GitHub de laatste maanden: stabiliteit / uptime. De reden die wordt gegeven: AI en agents.

Pitch van concurrent / alternatief: AI en agents.

Het enige dat een platform moet doen is code hosten en hoge uptime hebben, de rest is bijzaak / ruis. Dat Cursor / xAI hier mee komt is wat mij betreft geen selling point.

[Moortn]

Ik denk dat het wel degelijk een groot pluspunt kan zijn, mits het fatsoenlijk is uitgevoerd.

Als je toch alles met AI doet, misschien zelfs op basis van tickets die je al in Github/Gitlab/Gitea/Origin hebt staan, waarom zou je dan de code nog lokaal op een pc willen hebben i.p.v. alles "in de cloud" te doen en automatisch uit te rollen om te kunnen testen? Scheelt weer lokaal pullen en pushen. Product owners kunnen zo d.m.v. goede tickets van stakeholders wijzigingen aanbrengen zonder te hoeven wachten op developers. Desnoods maakt AI een PR die een developer moet goedkeuren.

Als je AI als hulpmiddel gebruikt dan heb je er iets minder aan, maar nog steeds denk ik dat AI hier een nuttige bijdrage kan leveren.

[Reactie gewijzigd door Moortn op 19 augustus 2026 16:18]

[Zarhrezz]

Maar om dingen "in de cloud" te kunnen doen, met die cloud wel bereikbaar zijn. En dat is nu precies waar bij GitHub het probleem het laatste jaar zit. Voor een hosting platform moet dat echt de hele top 3 van belangrijke dingen zijn. De rest komt daarna.

[koelpasta]

AI-programmeertool Cursor komt met een concurrent voor GitHub. Het platform gaat Cursor Origin heten en is bedoeld om code op te hosten.

Wat een kritiekloze marketingpraat weer.
De redacteur snapt, hoop ik, dat deze tool er enkel is om de AI van cursor te trainen op de code van de 'gebruikers'?

[Techno-Basje]

Ik zelfhost forgejo. Werkt als een trein.

[Pasteis]

Amerikaans bedrijf gaat de concurrentie aan met een ander Amerikaans bedrijf. En ondertussen slaat Europa zijn codebase nog in massale getallen op buiten de landsgrenzen…

Ik zou denken dat ook juist hierin kansen zijn voor Europese uitdagers zoals Codeberg?

[bantoo]

Ik denk niet dat mensen zitten te wachten op activistische hosters. Weer een gevalletje van platformen zonder reden tot gebruik buiten politieke voorkeuren om. Als je mensen op een Europees Platform wil hebben moet je iets maken wat beter is dan een Amerikaans pakket en toevallig Europees.