Cursor launched Origin in early beta on paid plans, and the framing in their own numbers is the interesting part: 35% of pull requests merged inside Cursor are opened by agents running autonomously in cloud VMs, not by humans. Once more than a third of your PR volume has no human sitting at a keyboard when it’s created, the tooling built around “a person committing code” starts showing its seams — and Origin is Cursor’s answer to that, not an incremental feature.

What Origin actually is

Origin is a Git forge — hosted codebases, pull requests with timeline/commits/checks/diffs, code browsing and search — that lives in a new Codebase tab inside Cursor, with two-way GitHub sync. The headline change: Cloud Agents no longer require a connected GitHub or other SCM provider to get started. You can prompt an agent cold, let it work in a cloud VM, and only decide afterward whether to save that work to an Origin repo, preview it live, or push it out to GitHub.

That ordering matters more than it sounds. Today, most agent-fleet workflows I’ve built or reviewed for clients follow: connect repo → clone → agent works in a branch → open PR → human reviews. Every step in that chain assumes the destination repo exists and is wired up before the agent starts. Origin inverts it: agent works first, repo gets decided later. That’s a genuinely different mental model for anyone building internal agent tooling — it treats “where does this code live” as a decision you can defer, not a prerequisite.

Why this matters beyond Cursor’s own product

I’ve run agent fleets against real client repos this year, and the actual bottleneck was never the agent’s code quality — it was the plumbing around getting an agent authenticated against a repo, scoped correctly, and cleaned up afterward if the task got abandoned half-done. A throwaway “let me see if this refactor is even feasible” prompt shouldn’t require provisioning a scoped GitHub token and a disposable branch first. Origin’s bet is that a large fraction of agent work is exploratory and should be free to start without that ceremony:

# Old flow: repo access is a prerequisite
git clone git@github.com:org/repo.git
# ... set up scoped token, branch, agent config ...
cursor-agent run --repo ./repo --task "explore whether X is feasible"

# Origin's flow: agent runs first, repo is a decision made after
cursor-agent run --task "explore whether X is feasible"
# only if it's worth keeping:
cursor-agent save-to-origin --name exploratory-x

The pseudo-CLI above isn’t Cursor’s actual API — I haven’t gotten off the waitlist yet — but it captures the sequencing shift that’s the actual point.

The GitHub-outage angle is not incidental

Origin’s launch got covered partly through the lens of a GitHub outage exposing “an opening in the AI coding race” — and that framing is worth taking seriously as a technical lead, independent of whether you buy the specific narrative. If a meaningful share of your team’s throughput now runs through agent fleets that assume GitHub availability at every step (auth, PR creation, status checks, webhooks), GitHub going down doesn’t just block human commits anymore — it blocks your agents’ entire operating loop. Two-way sync to an independent forge is, functionally, a redundancy layer you didn’t have before, whether or not that was the primary design goal.

What I’d actually check before adopting this

Before wiring Origin into a team workflow, the questions I’d want answered — and haven’t been able to fully answer from early beta coverage alone:

  1. Where does code review actually happen? If PRs exist natively in Origin and sync to GitHub, which one is the source of truth for review comments, approvals, and required-checks gating? Split review surfaces are a known way to lose track of who approved what.
  2. What’s the audit trail on agent-authored commits? With 35%+ of PRs agent-originated, “who approved this and under what prompt” needs to survive the sync round-trip, not just live in Cursor’s UI.
  3. Integration maturity. Vercel, Depot, and Buildkite integrations are live; more are coming. If your CI is Jenkins or a self-hosted runner, you’re likely waiting, and that’s a real gap for anyone not already on the supported stack.
  4. Waitlist-only beta risk. Don’t build critical-path tooling around a product still gating access — treat this as something to pilot on a low-stakes internal repo, not something to greenlight for your primary monorepo yet.

The takeaway

The interesting signal isn’t “Cursor built a Git host” — GitHub alternatives aren’t news. It’s that the product decided agent-authored code needed its own on-ramp, separate from the one built for humans, because forcing agent workflows through human-shaped infrastructure (connect a repo, get a token, open a PR) was measurably the friction point. If your team’s agent-authored PR percentage is climbing toward that 35% number, this is worth watching closely — not because Origin specifically will win, but because “the repo is a prerequisite” is exactly the kind of assumption that’s about to get re-litigated across the whole toolchain, not just at Cursor.

Export for reading

Comments