Cursor Origin — What We Actually Know About Cursor’s New Git Hosting

Cursor just announced Origin — its own code storage and git hosting. // Detect dark theme var iframe = document.getElementById('tweet-2067012220832329782-31'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2067012220832329782&theme=dark" } Waitlist: cursor.com/origin TL;DR Item Status Product name Origin What it is Git forge (host + review + collaborate) Built for Teams and AI agents Availability This fall (waitlist now) Pricing Not published Docs / GA details Not published What Origin is (in plain terms) Origin is Cursor’s move into the layer most of us still keep on GitHub/GitLab/Bitbucket: host repositories review changes collaborate on code Cursor’s own framing: A git forge for the agentic era And the supporting line on the landing page: Code is moving faster than any infrastructure was built to handle. Origin was designed for this moment. So the pitch isn’t “another GitHub clone.” It’s: forges built for human-paced work may struggle when agents push at machine speed. Confirmed (official sources only) These points come from Cursor’s X post and cursor.com/origin: Cursor is launching code storage and git hosting The product is called Origin It is for teams and agents It covers host, review, and collaborate Target window: this fall Access today: waitlist only That’s the trustworthy core. Everything else below should be labeled carefully. Reported from Compile coverage (not on the official landing page) Around Cursor’s Compile event (June 2026), tech coverage connected Origin to a broader story: Graphite DNA Origin is widely reported as building on Cursor’s Graphite acquisition (stacked PRs / high-volume review workflows). Agent-first workload Coverage describes demos with many parallel agents reading/writing the same repo — the kind of throughput traditional forges weren’t designed around. Agentic repo operations Reports mention agent help with things like: merge conflict resolution failed CI remediation comment handling Architecture mentions Some writeups cite a hybrid storage design (fast local/NVMe-style serving + object storage as source of truth). Treat performance numbers from demos as unverified claims until Cursor publishes docs. Important: these are reported details from event coverage. They are useful context, not a confirmed feature checklist for day one. Why this matters Until now, Cursor’s strength was the coding surface: editor agents writing/changing code review helpers like Bugbot / agent workflows The missing middle was always the forge: text IDE / Agents → Git Host + Review → CI / Ship ✅ ❓ ✅/external