Cursor Origin Guide

Cursor Origin is Cursor's code-hosting and git-forge move. Cursor's page says code is moving faster than existing infrastructure was built to handle. As of the checked date, the public page is a waitlist, so buyer and migration details remain thin.

Knowing what shipped is the easy part. Turning Cursor Origin into something a team relies on takes a few deliberate steps, mapped below.

1. 1Use Origin as a strategic signal first, not as a migration recommendation.
2. 2Map what would need proof before a team moved source hosting: identity, audit, branch protection, CI, reviews and data policy.
3. 3Compare Origin with GitHub on the review and agent-workload problem, not only repository hosting.
4. 4Refresh the page when Cursor publishes docs beyond the waitlist copy.

New capability comes with new ways to get it wrong. Keep these boundaries in place as you adopt it.

Origin was announced on stage at Cursor's Compile event on June 16, 2026, and it is built by the team behind Graphite, the stacked-diff code-review company Cursor acquired. The public story is short: a git forge designed for the volume of code that agents now produce. Cursor's demo framing was thousands of parallel agents pushing on the order of 22.6 commits per second. Everything else, from pricing to a firm launch date, remains unpublished.

This page tracks the head question: what Origin is and whether to care. The Cursor Origin deep-dive pillar goes further on each sub-question: why git hosting is being rebuilt for agents, how stacked diffs change review, what reviewing agent code looks like, how parallel agents avoid merge pile-ups, what a GitHub migration would involve and who holds your code.

Review before hosting. Cursor signed a definitive agreement to acquire Graphite on December 19, 2025, the Graphite founders build Origin from inside Cursor, and Tomas Reimers, one of the three co-founders, demoed it on stage at Compile. A team whose product was stacked pull requests is going to ship the review layer first, because that is the part they have already built once.

Which suggests, though this is inference and not something Cursor has published, that the thin part at launch will be the surrounding ecosystem: CI, marketplace apps, webhooks, the small integrations that accumulated around your current host without anybody deciding to adopt them.

That ordering is useful because it tells you what to evaluate on. If the review model is the piece arriving with a track record behind it, then judge Origin on review and merge, and treat repository hosting as table stakes it either has or does not. Hosting has been solved for years by several vendors. What nobody has settled is review at agent volume.

The honest caveat is that Cursor has published no feature list at all. The waitlist page carries no screenshots and no pricing, so every sentence about what Origin will be good at, including the two paragraphs above, is a read on the team rather than a read on the product.

A read on the team is still worth something when it is the only evidence going. It is not worth a migration plan.

Probably not yet, and it is worth being specific about why. The problem Origin aims at is review and merge throughput under a volume of change that agents produce. With six engineers and a couple of agents running, that is not your binding constraint. Your constraint is more likely that review is one person's spare attention on a Thursday.

A different problem needs a different fix.

To me the thing a small team can take from Origin today is the practice rather than the product. Reviewing small dependent changes in sequence is a way of working. It predates any particular tool, and it is available on the host you already pay for, which makes it a cheap experiment: run it for a fortnight and see whether your reviews get faster or merely more numerous.

At a few hundred engineers the calculation changes, because what Origin proposes to fix becomes measurable in your own numbers. Time from review-ready to merged. How many changes are sitting on a human at any given moment. What share of the queue an agent opened. How long the oldest waiting change has been waiting.

Collect those on your current host first, and start now. They are exactly what you would need in order to tell whether moving had helped, and there is no way to collect them retroactively once the move is done.

I would resist the framing where Origin becomes a hedge against your current host. You do not keep a spare source host. Either the review model earns a migration on its own terms, or the answer is no for another year.

Anything about throughput. The figure quoted above reached us through press coverage of the Compile demo rather than a Cursor document, which makes it a claim and not a benchmark. Worse, coverage of that demo has already produced errors: one widely shared commits-per-second number was traced to a different system, and a "50x faster" line came from GitLab rather than Origin. The commits-per-second page works through what the figure does and does not mean.

The rule that survives a security review is plain enough. If a number is not on cursor.com/origin or in a Cursor engineering post, it goes in the deck labelled as reported, or it does not go in.

Which sounds fussy right up until the first time somebody quotes your slide back at you in a procurement meeting.

Apply the same discipline to the date. Coverage points at a fall 2026 window and Cursor has published nothing, so a plan assuming availability inside this fiscal year is a plan resting on third-party reporting. That is allowed. Write the assumption down where whoever inherits the plan can find it, along with what happens to the plan if the window slips two quarters.