Cursor Launched a GitHub Competitor Three Hours Before GitHub Fell Over for Eight Hours. That Timing Is the Weakest Argument for Switching.

Cursor shipped Origin, its own code hosting platform, to paid users on Monday morning. Roughly three and a half hours later GitHub's status page went red and stayed that way for about eight hours, with error rates near 20% on web and API traffic and around 50% on some repository downloads. The incident ran from 13:40 to 21:15 UTC on August 17.

I have seen a lot of takes treating that sequence as the universe endorsing a product launch. It isn't, and if you run your business off one laptop the coincidence is the least useful thing about this release.

What Origin actually is

Origin gives you repositories, pull requests, code browsing, reviews, merges, and CI connections inside Cursor. The part that matters more than any of those is GitHub sync: you can connect a GitHub organisation, pull existing repos into Origin, and keep pull request comments flowing between the two.

That is a bridge, not a migration. Cursor's own framing is that Origin interoperates with GitHub rather than replacing it, and coverage that led with "GitHub alternative" mostly skipped past the sync design to get to the horse race.

The review layer has a real pedigree. Cursor acquired Graphite in December 2025, the company that popularised stacked pull requests, where you ship dependent changes without waiting on each one to be approved in sequence. Graphite's team and technology sit underneath Origin's review workflow. If you have ever had four small PRs blocked behind one slow review, that is the problem this lineage was built for.

Cursor's pitch is that this is code hosting built for "agent scale." I read that as an admission about volume. When an agent opens eleven pull requests in an afternoon, the bottleneck stops being how fast you write code and starts being how fast the review surface lets you triage. Whether Origin actually solves that or just relocates it is an open question I cannot answer from a changelog.

Why the outage is the wrong reason to move

Here is the argument I keep seeing: GitHub broke, Cursor shipped a replacement, therefore diversify to Cursor.

Follow that reasoning and look at where you land. My stack, and probably yours, already routes an enormous amount through a small number of vendors. If your editor, your coding agent, your review tool, and your git remote all become one company, you have not diversified. You have taken four independent failure domains and welded them into one. The next incident does not degrade one thing you use, it degrades everything at once, and you will not even have a working local remote to push to while you wait.

The correct response to an eight-hour GitHub outage is boring: know where your code lives when GitHub is unavailable. Git is distributed. Your clone is a complete repository. A second remote on a different provider costs nothing and takes about ninety seconds to configure. That gives you actual redundancy, which is a different thing from having a second account at a company whose product roadmap depends on your first one.

Worth noting what the outage did and did not touch. Pull requests, issues, Actions, Pages, webhooks, the API, and Copilot were all affected. Your local repository was not. Almost everyone who "could not work" on Monday could in fact still commit; what they could not do was collaborate, run CI, or get an agent to talk to the API. That distinction is the entire redundancy plan.

What I would actually do

Try Origin. I mean that without sarcasm and without it contradicting anything above.

The sync-first design is what makes it low-risk to evaluate. You connect an organisation, mirror a repo, and your GitHub remote stays exactly where it is. If the stacked-review workflow speeds up how you handle a pile of agent-generated pull requests, you learned something valuable for the price of an afternoon. If it doesn't, you turn it off and nothing moved.

What I would not do is make Origin the canonical home for anything I would be upset to lose, at least not this quarter. It rolled out on Monday. The failure modes of a code host are not the kind you discover in week one, they are the kind you discover during the first bad incident, and Origin has not had one yet in public.

So: mirror, don't migrate. Add a second remote somewhere unrelated to your editor vendor. And treat the launch-day outage as what it was, a coincidence with good comic timing, rather than a data point about where your source code should live.

The honest counter-take

The strongest case against my position is that concentration risk is a thing solo operators talk about far more than they act on, and that the practical benefit of a tightly integrated toolchain is real and immediate while the cost is hypothetical and rare.

That is a fair hit. I have never lost a day to a vendor bundling too much. I have lost plenty of days to switching context between four tools that do not know about each other. If Origin genuinely collapses that friction, an honest cost-benefit might come out in favour of concentration for a one-person shop, where the coordination overhead is the actual daily tax and the eight-hour outage is a once-a-year annoyance.

I still would not put my only copy there yet. But "wait and see" is not the same as "this is a bad idea," and I want to be clear about which one I am arguing.

Author

Lukas

@lukcombinator

Sources

• Cursor Launches 'Origin' Code Hosting Platform As GitHub Alternative
• Cursor launches Origin code hosting service to compete with GitHub
• GitHub suffers eight-hour outage affecting Actions, APIs, and Copilot
• Cursor launches Origin, a code hosting platform built for AI coding agents with GitHub sync
• Microsoft confirms GitHub is down worldwide