Cursor Origin: nový GitHub pro AI agenty? Co umí a jak funguje vedle GitHubu

GitHub měl 17. srpna 2026 opravdu špatný den. Rozsáhlý incident zasáhl API, Pull Requests, Issues, Actions, Webhooks i Copilot a podle oficiálního GitHub Status trval od 13:28 do 21:15 UTC. V jednu chvíli GitHub hlásil přibližně 20% chybovost webu a API, zatímco stahování archivů a raw obsahu repozitářů selhávalo přibližně v polovině případů.

A právě 17. srpna začal Cursor zpřístupňovat Origin – vlastní platformu pro hosting Git repozitářů. Cursor ji popisuje jako Git forge navrženou pro škálu AI agentů a v early beta nabízí repozitáře, pull requesty, procházení kódu a synchronizaci s GitHubem.

Na první pohled se nabízí jednoduchý příběh: GitHub spadl a Cursor toho využil ke spuštění vlastní alternativy.

Realita je zajímavější.

Origin není projekt, který by Cursor vytvořil přes víkend během výpadku GitHubu. Cursor na vlastní Git infrastruktuře pracoval už dlouho předtím a den po spuštění early beta zveřejnil podrobný technický rozbor systému Continuity, který pod Originem běží.

Ještě důležitější je, že Cursor zatím vývojáře nenutí GitHub opustit. Origin může fungovat vedle GitHubu, synchronizovat jeho repozitáře a později se od něj případně úplně oddělit.

A právě tím začíná být Origin podstatně zajímavější než jen další web, na který lze udělat git push.

Co je Cursor Origin

Origin je vlastní Git forge Cursoru.

Pojmy Git, GitHub a Git forge je dobré od sebe odlišit.

Git je distribuovaný verzovací systém. GitHub je platforma postavená nad Gitem, která k samotnému ukládání repozitářů přidává pull requesty, Issues, Actions, správu týmů, oprávnění, balíčky, bezpečnostní nástroje a obrovský ekosystém dalších služeb.

Git forge je obecné označení pro platformu, která Git repozitáře hostuje a staví nad nimi nástroje pro spolupráci. Patří sem například GitHub, GitLab, Bitbucket – a nově také Origin.

Cursor Origin přitom nevytváří vlastní náhradu Gitu. Funguje se standardním Gitem a repository lze klonovat přes běžnou HTTPS adresu:

git clone https://origin.cursor.com/acme/checkout.git

Stejně fungují git fetch, git pull nebo git push. Vedle toho Cursor nabízí vlastní CLI nástroj origin, který zjednodušuje správu repozitářů a pull requestů.

Origin je v tuto chvíli stále early beta. Cursor 17. srpna oznámil postupné zpřístupnění uživatelům placených plánů.

To je důležitý kontext pro celý článek: Origin už je reálně použitelná Git platforma, ale rozhodně ještě není hotovou náhradou celého GitHub ekosystému.

Cursor spustil Origin právě v den velkého výpadku GitHubu

Načasování bylo pro Cursor téměř dokonalé.

Zatímco Cursor 17. srpna spouštěl early beta svého vlastního code hostingu, GitHub bojoval s rozsáhlým výpadkem.

GitHub Status následně popsal incident trvající 7 hodin a 47 minut, který zasáhl mimo jiné Issues, Pull Requests, API, Actions a Copilot. V průběhu incidentu GitHub informoval o zhruba 20% chybovosti webových a API požadavků a přibližně 50% chybovosti u stahování archivů a raw repository obsahu.

Je ale důležité nezaměňovat perfektní timing za příčinu.

Neexistuje důkaz, že by Cursor Origin spustil proto, že GitHub právě vypadl. Launch byl výsledkem dlouhodobějšího vývoje.

Výpadek však dokonale ukázal jeden z problémů, na který Cursor svou novou platformou míří.

GitHub už dávno není pouze místo, kde leží .git repository. Pro mnoho firem přes něj běží code review, CI/CD, deployment, autentizace, projektové řízení i AI nástroje. Když taková platforma přestane fungovat, dopad může zasáhnout prakticky celý software-development workflow.

S nástupem AI agentů se přitom množství automatizované práce kolem repozitářů dál zvyšuje.

Co Cursor Origin aktuálně umí

Základní nabídka Originu už připomíná klasickou Git forge.

V early beta Cursor oficiálně uvádí možnost:

• vytvářet a hostovat Origin repositories,
• klonovat, pushovat a pullovat pomocí standardního Gitu,
• mirrorovat GitHub repository,
• otevírat, reviewovat a mergovat pull requesty,
• procházet a vyhledávat kód v prohlížeči,
• spravovat repository a codebase settings,
• připojovat cloudové agenty a automatizace,
• používat integrace jako Vercel, Depot a Buildkite,
• pracovat přes Origin CLI.

Pull requesty mají vlastní activity, commits, checks a changed files. Cloud agent navíc může pull request otevřít jako součást zadaného úkolu.

Právě integrace agentů odlišuje Origin od obyčejného „nového Git hostingu“.

Cursor totiž nestaví pouze místo, kde člověk uloží kód. Staví místo, ve kterém mohou nad stejným repozitářem pracovat lidé i autonomní agenti.

Origin nemusí GitHub nahradit. Může fungovat vedle něj

Tohle je pravděpodobně nejzajímavější vlastnost Originu pro běžného vývojáře.

Pokud máš projekt na GitHubu, nemusíš ho z něj odstranit ani okamžitě kompletně migrovat.

Origin nabízí GitHub mirroring.

Workflow může vypadat například takto:

GitHub
   ↓
Origin mirror
   ↓
Cursor agents
   ↓
Origin browsing / search / PR

Cursor zkopíruje GitHub repository do Originu a následně jeho kopii průběžně aktualizuje.

GitHub přitom zůstává source of truth – tedy hlavním zdrojem pravdy pro repository. Cursor v nastavení synchronizovaného repozitáře skutečně zobrazuje GitHub jako source a Origin jako mirror.

To je chytrý způsob, jak Origin dostat mezi existující uživatele GitHubu.

Nemusíš udělat riskantní rozhodnutí „GitHub, nebo Cursor“. Můžeš nejdřív připojit Origin k existujícímu workflow a zjistit, jestli ti přináší nějakou hodnotu.

Co se mezi GitHubem a Originem synchronizuje

Cursor aktuálně uvádí následující rozsah synchronizace:

Synchronizuje se	Nesynchronizuje se
Git historie	GitHub Issues
branches	GitHub Actions workflows
tags	GitHub Actions secrets
repository code	další GitHub-specific CI konfigurace
pull requesty
průběžné změny repository

Pull requesty se přitom synchronizují oběma směry. PR dostupný na GitHubu lze zobrazit a používat v Originu a změny se vracejí zpět na GitHub.

To už je podstatně hlubší integrace než obyčejná záložní kopie repository.

Pull requesty se synchronizují oběma směry

U mirrorovaného GitHub repository dokáže Origin s GitHub pull requesty pracovat tak, jako kdyby šlo o vlastní Origin PR.

Cursor dokumentuje, že uživatel může GitHub pull requesty v Originu zobrazit a interagovat s nimi a provedené změny se synchronizují zpět na GitHub.

Prakticky tedy může vzniknout workflow:

GitHub repository
        ↓
    Origin mirror
        ↓
    Cursor agent
        ↓
      branch
        ↓
      commit
        ↓
    pull request
        ↓
GitHub + Origin

Pro firmy už dnes silně navázané na GitHub je právě tohle pravděpodobně mnohem realističtější cesta než okamžitá migrace.

Origin lze později od GitHubu úplně odpojit

Mirroring ale nemusí být konečný stav.

Cursor v nastavení nabízí funkci Detach from GitHub.

Po jejím použití se synchronizace zastaví a kopie uložená v Originu se změní na samostatné Origin-hosted repository.

V tu chvíli se Origin stává source of truth.

Další push do Originu už není posílán na GitHub. Původní GitHub repository přitom zůstane beze změny.

Z toho vzniká velmi zajímavá migrační cesta:

1. GitHub

       ↓

2. GitHub + Origin mirror

       ↓

3. testování Originu a agent workflow

       ↓

4. Detach from GitHub

       ↓

5. samostatný Origin

Tady už se dostáváme od potvrzených technických faktů k produktové interpretaci.

Je těžké přehlédnout, jak nízké tření tato strategie vytváří.

Cursor po vývojářích nechce, aby se nejdřív vzdali GitHubu a teprve potom zjistili, jestli Origin funguje. Umožní jim nejdřív Origin přidat vedle existující infrastruktury a úplné odpojení nechat až na později.

Pokud chce Cursor dlouhodobě získávat workload z GitHubu, je to velmi chytrý onboarding.

GitHub a Origin mohou být také dva samostatné Git remotes

Mirroring není jediná možnost.

Cursor přímo dokumentuje konfiguraci standardního Gitu, při které se push odešle na GitHub i Origin.

Například:

git remote set-url --add --push origin git@github.com:acme/checkout.git

git remote set-url --add --push origin \
https://origin.cursor.com/acme/checkout.git

Cursor tuto možnost popisuje jako způsob, jak držet GitHub a Origin paralelně během vyhodnocování Originu. Pro kompletní přenos historie ale doporučuje vlastní mirroring.

To je důležitý rozdíl.

U mirroru vypadá architektura přibližně takto:

Developer
    ↓
 Origin
    ↓
 GitHub
(source of truth)

U dvou push destinations:

         → GitHub
Developer
         → Origin

Ve druhém případě využíváš jednu z přirozených vlastností samotného Gitu – repository nemusí mít pouze jeden vzdálený cíl.

Pozor: GitHub mirror není automatický failover

Tady přichází velmi důležitá nuance.

Mohlo by být lákavé říct:

Když GitHub vypadne, mám přece repository na Originu.

Pro čtení kódu může mít mirror samozřejmě velkou hodnotu. Origin drží kopii Git historie a umožňuje ji browsovat, prohledávat nebo klonovat.

Jenže Cursor zároveň explicitně uvádí, že u synchronizovaného repository push do Originu prochází přes GitHub, protože právě GitHub zůstává source of truth.

Z toho vyplývá, že GitHub mirroring nelze automaticky považovat za plnohodnotný active-active disaster-recovery mechanismus.

Tohle už je technická inference z dokumentovaného chování, nikoli tvrzení Cursoru.

Pokud je GitHub source of truth a write operace na něj stále závisejí, jeho kompletní nedostupnost může ovlivnit i write workflow nad mirrorovaným repozitářem.

Takže tvrzení „GitHub spadne, ale s Originem prostě pokračuješ bez omezení“ by v tuto chvíli bylo příliš silné.

AI agenti jsou skutečný důvod, proč Origin dává smysl

Samotný Git hosting dnes není žádná převratná technologie.

Podstatné je, pro koho Cursor Origin navrhuje.

Cursor dlouhodobě posouvá svůj produkt od AI našeptávače k autonomnějším agentům schopným vykonávat celé vývojářské úkoly.

Cloud agent může nad Origin repository:

clone
  ↓
vytvořit branch
  ↓
upravit kód
  ↓
commit
  ↓
push
  ↓
otevřít pull request

Cursor dokumentuje, že cloudoví agenti mohou nad existujícími Origin repositories klonovat kód, vytvářet branche, commitovat, pushovat a otevírat pull requesty. Agent dokonce může nové Origin repository sám vytvořit přes Origin CLI.

To mění samotnou ekonomiku Git infrastruktury.

Jeden lidský programátor může pracovat na několika změnách denně.

Ale co když jeden programátor současně deleguje práci pěti agentům?

A každý z nich paralelně:

• vytváří branche,
• čte repository,
• generuje změny,
• commitne kód,
• otevře PR,
• vyvolá CI,
• reaguje na review,
• provede další commit.

Najednou nemusí počet Git operací růst stejně rychle jako počet vývojářů.

Může růst mnohem rychleji.

Cursor ve svém technickém rozboru Originu přímo píše, že agenti znamenají více kódu, více pull requestů a více CI runs.

A tady se dostáváme k technologicky nejzajímavější části Originu.

Continuity: Cursor si postavil vlastní Git storage systém

Pod Originem běží vlastní systém Cursoru nazvaný Continuity.

A Cursor ho nepostavil jen proto, aby měl Git repository na jiné doméně než github.com.

Jde o pokus řešit omezení tradiční architektury Git hostingu při extrémním horizontálním škálování.

Git je totiž pro hosting překvapivě komplikovaný systém.

Repository obsahuje objekty uložené v packfiles a mnoho Git operací musí procházet graf vzájemně navázaných commitů, stromů a blobů. Náhodný přístup napříč velkým množstvím dat navíc znamená, že obyčejné vzdálené filesystemy nejsou ideálním řešením.

Velké Git hostingové systémy proto používají sofistikovanou replikaci lokálních kopií repozitářů.

Cursor ve svém rozboru podrobně popisuje architekturu Spokes, která vznikla v GitHubu a ovlivnila způsob provozu velkých Git hostingových služeb. Repository existuje v několika konzistentních kopiích na rychlých lokálních discích a změny se mezi nimi synchronizují.

To dlouhé roky fungovalo velmi dobře.

Agentický svět ale podle Cursoru vytváří dva extrémy.

Na jedné straně jsou obrovská monorepa zatěžovaná vysokým množstvím CI operací.

Na druhé straně mohou agenti generovat obrovské množství malých, někdy téměř jednorázových repositories.

Tradiční architektura potřebující několik plnohodnotných konzistentních replik každého repozitáře tak podle Cursoru naráží současně na příliš vysoký minimální overhead a omezený maximální scale.

Write-ahead log v S3 jako source of truth

Continuity řeší problém jinak.

Jeho základním prvkem je write-ahead log neboli WAL, který Cursor ukládá do S3-compatible object storage.

V produkci Cursor používá přímo Amazon S3, ale architektura podle firmy není pevně vázaná pouze na AWS.

Při pushi systém změnu uloží do WAL.

Cursor uvádí, že push nikdy nepotvrdí klientovi dřív, než je kompletně persistentně uložený.

Lokálně přitom stále používá obyčejné Git repository na rychlém NVMe disku.

Zjednodušená architektura tedy vypadá přibližně takto:

               S3
        Write-Ahead Log
        source of truth
               │
      ┌────────┼────────┐
      ↓        ↓        ↓
    NVMe     NVMe     NVMe
    Git      Git      Git
  replica  replica  replica

Klíčový rozdíl je v tom, co se považuje za definitivní zdroj dat.

U Continuity jsou lokální repository podle Cursoru v zásadě warm cache.

Source of truth představuje WAL v S3.

Repository může existovat prakticky kdekoliv

To má zajímavý důsledek.

Continuity nemusí podle Cursoru držet každé repository permanentně na přesně stanovené sadě serverů.

Pokud lokální kopie chybí, lze ji z WAL znovu materializovat.

V produkci Cursor používá rendezvous hashing, aby věděl, na kterých nodech by konkrétní repository ideálně mělo být. Samotná správnost systému ale na této routovací informaci nestojí.

Aktualizace WAL se synchronizují atomickou compare-and-swap operací v S3.

To Cursoru umožňuje škálovat počet lokálních replik podle reálného workloadu.

Velké vytížené monorepo může mít mnoho kopií.

Malé repository může mít jednu.

A neaktivní repository nemusí mít na lokálním disku žádnou permanentní kopii – lze jej znovu vytvořit ve chvíli, kdy přijde další požadavek.

Pro svět, ve kterém agenti mohou vytvářet obrovské množství malých dočasných repositories, je to zásadní vlastnost.

Od jednoho idle repository po stovky replik

Cursor tvrdí, že právě WAL-first architektura umožňuje Continuity škálovat v obou směrech.

Nejen nahoru, ale i dolů.

Klasická otázka distribuovaného systému bývá:

Kolik replik potřebuji, abych zvládl co největší zatížení?

Cursor k tomu přidává druhou:

Jak levně dokážu provozovat miliony repozitářů, které skoro nikdo nepoužívá?

U agentických systémů může být druhá otázka stejně důležitá jako první.

Cursor popisuje scénář, kdy velké monorepo obsluhují stovky replik, zatímco miliony drobných agent-created repositories mohou fungovat s jedinou lokální kopií nebo být z lokálního disku úplně odstraněny a později znovu vytvořeny.

To je podle mě jedna z nejdůležitějších myšlenek celého Originu.

Nejde jen o vyšší maximální výkon.

Jde o jiný profil workloadu.

Cursor ve vlastních testech uvádí přes 300 pushů za sekundu

Cursor už zveřejnil i první výkonnostní čísla Continuity.

A tady je důležité být přesný.

Nejde o nezávislý benchmark Originu proti GitHubu.

Jde o syntetické stress testy provedené samotným Cursorem na vlastní infrastruktuře.

Cursor uvádí testování s až 100 replikami, při kterém read-only Git operace škálovaly lineárně bez snížení push throughputu.

Při použití běžného S3 Standard Cursor uvádí schopnost udržet až přibližně:

120 pushů za sekundu.

Na nízkolatenčním S3 Express One Zone pak uvádí:

více než 300 pushů za sekundu.

V tomto bodě už podle Cursoru nebylo hlavním omezením S3, ale rychlost Git compaction operací nad daty na disku.

Čísla jsou působivá.

Zatím ale dokazují především potenciál architektury v laboratornějším scénáři Cursoru, nikoli to, že Origin automaticky poráží GitHub v reálném produkčním provozu.

Na takový závěr zatím nezávislá data nemáme.

Origin není jen web. Má vlastní CLI a API

Dalším důležitým signálem je, že Cursor nestaví Origin pouze jako funkci svého editoru.

Existuje samostatné Origin CLI.

Po instalaci například:

origin auth login

A následně lze přes CLI vytvářet a spravovat repositories nebo pracovat s pull requesty.

Dokumentované skupiny příkazů zahrnují mimo jiné:

origin auth
origin repo
origin pr
origin ruleset
origin ssh-key

Cursor navíc dokumentuje interní aplikace používající vlastní Origin API, autentizované pomocí app JWT a installation access tokenů.

To je důležitý detail.

Jakmile má platforma Git storage, oprávnění, API, CLI, applications a integrations, přestává být pouhou funkcí editoru.

Začíná z ní být samostatná developer platforma.

Vercel, Depot a Buildkite

V early beta lze k Origin repository připojit několik externích služeb.

Cursor aktuálně dokumentuje:

Vercel – push může spustit deployment a pull request získat preview environment.

Depot – CI pro Origin-hosted repositories.

Buildkite – CI pro Origin-hosted repositories.

Je zde ale další podstatné omezení.

Depot a Buildkite jsou přes tuto integraci určeny pouze pro Origin-hosted repositories.

U repozitářů mirrorovaných z GitHubu Cursor uvádí, že CI zůstává na GitHubu.

Hybridní režim tedy skutečně znamená hybridní režim.

Kód a PR můžeš dostat do Origin workflow, ale všechny části GitHub infrastruktury se automaticky nepřestěhují.

Co Origin zatím neumí

Tady je potřeba ubrzdit představu o „GitHub killerovi“.

GitHub není jen místo pro Git repository.

Je to dvacet let budovaný ekosystém.

Při GitHub mirroringu se do Originu například nepřenášejí:

• GitHub Issues,
• GitHub Actions workflows,
• GitHub Actions secrets.

Origin sice nabízí vlastní rules a protections, permissions a několik integrací, Cursor ale sám upozorňuje, že některá UI a controls se během early beta ještě mění.

Dalším omezením je visibility.

Aktuální dokumentace pro vytvoření Origin repository nabízí pouze:

Internal

a

Private.

Nebylo by proto přesné kategoricky napsat, že Origin „neumí veřejná repository navždy“. Přesné tvrzení je, že současný create flow early beta veřejnou variantu nedokumentuje.

Pro platformu, která by chtěla kompletně nahradit GitHub a jeho roli v open source, jde samozřejmě o zásadní mezeru.

Kolik Cursor Origin stojí

Origin zatím nemá samostatný tarif.

Cursor uvádí, že code storage Originu je dostupný uživatelům plánů Pro, Teams a Enterprise, nikoli free plánu. Přístup se navíc otevírá postupně, takže ho nemusí okamžitě vidět každý placený uživatel.

K 19. srpnu 2026 uvádí Cursor základní cenu:

• Pro – 20 dolarů měsíčně
• Teams – 40 dolarů za uživatele měsíčně
• Enterprise – individuální cena.

Nejde ale o „cenu Originu“. Origin je aktuálně součástí podporovaných placených plánů Cursoru.

Protože se pricing SaaS služeb rychle mění, je dobré brát tato čísla jako stav v době vydání článku.

A co soukromí zdrojového kódu?

Tohle bude u Git hostingu pro firmy pochopitelně jedna z prvních otázek.

Cursor uvádí, že Origin respektuje Privacy Mode vlastníka namespace, tedy jednotlivce nebo týmu, kterému repository patří.

Cursor současně u svého pricingu tvrdí, že při zapnutém Privacy Mode nejsou code data používána k trénování Cursoru ani jeho model providers.

Přesná formulace je tady důležitá.

Není vhodné tvrdit, že Cursor „nikdy nepoužívá kód k trénování“.

Správné je, že Cursor tuto garanci uvádí pro data při zapnutém Privacy Mode.

U firemních repozitářů pak samozřejmě vedle marketingových tvrzení přicházejí na řadu další otázky kolem compliance, auditu, dostupnosti, smluvních garancí, regionálního ukládání dat a dlouhodobé provozní historie.

Právě tam má GitHub oproti několik dní staré early beta platformě obrovský náskok.

Cursor už navíc není samostatný startup

Do širšího kontextu Originu patří ještě jedna zásadní změna.

Pouhé tři dny před spuštěním Originu oznámil Cursor, že byl oficiálně koupen SpaceX.

Akvizici Cursor oznámil 14. srpna 2026 s tím, že proces navazoval na dřívější spolupráci se SpaceXAI kolem trénování modelů.

Pro Origin je to relevantní hlavně strategicky.

Budování globální Git infrastruktury, AI modelů a cloudových agentů je extrémně kapitálově a infrastrukturně náročná disciplína.

Cursor už tedy nelze hodnotit pouze jako startup stavějící populární AI editor.

Je součástí výrazně větší technologické infrastruktury.

Je Cursor Origin skutečně konkurence GitHubu?

Ano. Ale zatím ne tak, jak naznačuje označení „GitHub killer“.

Na technické úrovni Origin GitHubu konkuruje už dnes.

Dokáže hostovat Git repositories.

Má pull requesty.

Má permissions a protections.

Má browser pro kód.

Má CLI.

Má API.

Má základní integrations.

A má vlastní distributed Git storage infrastrukturu.

To už není jen doplněk editoru.

Současně ale Origin zatím nemá rozsah funkcí ani ekosystém GitHubu.

GitHub je kromě code hostingu také:

• centrum obrovské části open-source světa,
• CI/CD platforma díky Actions,
• issue tracker,
• marketplace,
• package registry,
• security platforma,
• identity a collaboration layer pro velkou část vývojářské komunity.

Origin je proti tomu stále early beta.

Proto bych dnes neřekl, že Cursor vytvořil „nový GitHub“.

Přesnější je:

Cursor začal stavět vlastní GitHub pro agentickou éru.

A to je strategicky možná zajímavější.

Proč může být právě spojení s AI agenty největší výhodou

GitHub vznikl v roce 2008 v úplně jiném světě.

Hlavními aktéry software-development workflow byli lidé.

Člověk napsal kód.

Člověk vytvořil branch.

Člověk commitnul změny.

Člověk otevřel pull request.

Další člověk jej reviewoval.

Automatizace samozřejmě postupně přibývala, ale základní model zůstával human-first.

Agentický vývoj může tuto rovnováhu změnit.

Představ si vývojáře, který nepíše jednu změnu, ale současně řídí pět cloudových agentů.

Jeden opravuje bug.

Druhý refaktoruje API.

Třetí píše testy.

Čtvrtý řeší dependency update.

Pátý staví novou feature.

Každý přitom pracuje nad Gitem.

A každý vytváří nový workload:

repository reads
        +
branches
        +
commits
        +
pushes
        +
pull requests
        +
reviews
        +
CI runs

Git infrastruktura najednou nemusí škálovat podle počtu zaměstnaných programátorů.

Může škálovat podle počtu současně pracujících agentů.

Právě proto je Continuity možná důležitější než samotné UI Originu.

Má smysl na Origin přecházet už dnes?

Pro většinu vývojářů bych dnes neviděl důvod bezhlavě migrovat všechno z GitHubu.

Origin je příliš nový a GitHub má příliš velký ekosystém.

Ale existuje několik zajímavých scénářů.

Používáš Cursor a máš projekty na GitHubu

Nejlogičtější je dnes pravděpodobně:

GitHub
   +
Origin mirror

Zachováš GitHub jako source of truth a současně můžeš vyzkoušet Origin browsing, pull request workflow a cloudové agenty.

Chceš Origin opravdu testovat jako Git hosting

Můžeš si vytvořit samostatné Origin repository a pracovat s ním přes standardní Git.

Chceš mít oba hostingy paralelně

Standardní Git umožňuje nastavit push na GitHub i Origin.

Chceš z GitHubu odejít

Mirror může sloužit jako mezikrok a později lze použít Detach from GitHub, po kterém se Origin stane samostatným source of truth.

To je podle mě mnohem zajímavější než klasické „exportuj všechno a doufej, že migrace vyjde“.

Origin zatím není GitHub killer. Ale možná řeší jiný problém

Největší chyba by byla hodnotit Cursor Origin pouze podle seznamu dnešních funkcí.

Pokud vedle sebe postavíme GitHub a několik dní starou early beta platformu a budeme odškrtávat features, výsledek je předvídatelný.

GitHub vyhraje.

Jenže Cursor podle všeho nesází na to, že vytvoří trochu hezčí GitHub.

Sází na mnohem větší změnu.

Na vývoj softwaru, ve kterém už Git infrastrukturu nezatěžují jen lidé, ale obrovské množství autonomních agentů.

Cursor kvůli tomu nepostavil jen nové webové rozhraní.

Postavil vlastní distribuovaný Git storage systém, změnil model replikace, použil write-ahead log v object storage jako source of truth a navrhl infrastrukturu schopnou škálovat od téměř neaktivních malých repositories až po extrémně vytížená monorepa.

Ve vlastních syntetických testech už Cursor ukazuje stovky pushů za sekundu.

To zatím neznamená, že je Origin rychlejší, spolehlivější nebo lepší než GitHub v reálném světě.

Znamená to ale, že Cursor řeší problém, který podle něj teprve začne být opravdu velký.

A jestli má pravdu, možná se za pár let nebudeme ptát:

Je Origin lepší GitHub?

Mnohem zajímavější otázka může znít:

Je dnešní vývojářská infrastruktura vůbec připravená na svět, ve kterém jeden člověk současně řídí desítky AI agentů?

Origin je zatím jedna z prvních vážných sázek na to, že odpověď zní ne.