Cursor Origin: What It Is, How It Differs from GitHub, and How to Try It

The short answer

Cursor Origin is Cursor’s own git forge, in early beta since August 17, 2026. You can create repositories that live on Origin, clone and push with standard git, open and merge pull requests, browse and search code at cursor.com/codebase, and point Cursor’s cloud agents at those repos. You can also mirror an existing GitHub repository into Origin. On an Origin-hosted repo, Origin is the source of truth. On a mirrored repo, GitHub stays the source of truth and Origin keeps a copy.

Four facts shape most decisions. First, Origin is not on every plan: Cursor’s docs say it is not available on Free or Plus, and the pricing page we read on October 30, 2026 lists it from Premium upward. Second, the mirror is not a two-way code sync: code flows from GitHub into Origin, while only pull request conversation is described as syncing both ways. Third, Origin does not sync GitHub Issues or GitHub Actions workflows and secrets, so CI runs through partner apps instead. Fourth, it is a beta, and Cursor says plainly that features and permissions screens may change.

This guide is built from Cursor’s launch changelog, its Origin docs, the Origin API reference, the Origin landing page, the pricing page, Cursor’s community forum thread, and two press pieces that are labeled as press where we use them. We did not run Origin ourselves for this article, and Cursor has not published performance, uptime or retention numbers that we could cite, so none appear here. If you are working out which plan to buy, read our Cursor pricing and X subscription plans guide alongside this one.

When Origin launched

The launch date is on Cursor’s own changelog. The entry titled Origin Code Hosting sits under the date August 17, 2026 in the changelog feed, and the same day a Cursor staff member posted the announcement on the community forum with a post time of 5:42 pm UTC. The changelog text says, “Origin begins rolling out today in early beta on all paid plans.” The forum post adds that access opens in stages, so some paid accounts did not see it immediately.

Press coverage agrees on the day. VentureBeat’s story is stamped August 17, 2026 and InfoQ’s URL is in its August 2026 archive. The research behind this guide did not find a first-party date for anything earlier, such as a preview or waitlist announcement. A trade site reported that Cursor first announced Origin on June 16 and had planned to launch on August 11, and a LinkedIn repost shows Cursor saying Origin was “available this fall” with a waitlist. We have not been able to tie either claim to a dated Cursor page, so treat the June date and the August 11 plan as unverified. The only launch date Cursor itself has published, as far as we could find, is August 17, 2026.

Since launch Cursor has kept shipping around Origin. The changelog shows a change on August 27 that lets cloud agents start without any connected source control provider and then save work to an Origin repo, and on October 13 an Origin App Marketplace. Both are covered below.

What Origin is

Cursor’s own definition is short: Origin is “Cursor’s git forge for storing and sharing code.” A forge is the server side of a team’s workflow, the place where repositories, access control, pull requests and review live. GitHub, GitLab and Bitbucket are forges. Origin is Cursor’s entry in that category, and the landing page describes it as “a git forge for the agentic era.”

The docs list what you can do in early beta: create repositories, including from Cursor agents; clone, push and pull with standard git; mirror a GitHub repository; open, review and merge pull requests, with Code Tours that walk reviewers through each one; browse and search code at cursor.com/codebase; manage repository and codebase settings; install Origin Apps; create private Origin Apps against the public API; connect automations and cloud agents; and install the Origin CLI. Repo URLs have the shape cursor.com/codebase/{owner}/{repo} in the browser and https://origin.cursor.com/{owner}/{repo}.git for git.

Before anything else, someone has to claim a codebase name. That name is the namespace, the {owner} in every repo URL. Cursor’s docs warn that during the beta you cannot change or update the namespace once it is claimed, so choose it with the same care you would give an organization name. Any team member can claim it from cursor.com/codebase, and admins can disable Origin for the team at any time from the dashboard.

Origin also has its own command line tool, origin, separate from the Cursor Agent CLI. It handles sign-in, repo creation and deletion, SSH key registration, pull request commands and an origin push local command that we explain in the mirrored-repo section. Cursor’s docs say signing in with the CLI also sets up the git credential helper, so plain git push and git pull work against Origin remotes afterward.

Which plans include Origin

Plan access is the part most readers ask about, and it is easy to get wrong because Cursor’s wording changed. The launch changelog said “all paid plans.” The forum announcement named Pro, Teams and Enterprise. The current Origin docs say: “Origin code storage is available on Premium, Super, Ultra, Teams, and Enterprise, and on the legacy Start, Pro, Pro+, and Ultra plans. It is not available on Free or Plus.” The pricing page agrees, with a feature row called “Code hosting via Origin.” The table below combines the two as of October 30, 2026.

Three details matter beyond the grid. Teams on legacy privacy mode cannot enable Origin, so you need to switch to Privacy Mode first. Mirroring a GitHub repo needs the Cursor GitHub app connected to the owning org or account and GitHub admin access on that repository. And the pricing page notes that third-party models inside Cursor are billed separately by usage, which means the plan price covers the Origin feature but not the cost of agent runs on frontier models. For plan-by-plan prices and how usage pools work, the pricing guide goes further. Cursor has not published a separate price for Origin storage or bandwidth in the pages we read, and a VentureBeat article written at launch said Origin’s pricing was unpublished then.

Origin-hosted vs GitHub-mirrored repos

This is the distinction that decides how Origin behaves, and the one most summaries blur. A repo in the Codebase tab is one of two kinds, and an icon next to the name tells you which.

An Origin-hosted repo is created on Origin, either with New in the web UI, with origin repo create, or by a Cursor agent. Cursor’s changelog says: “For Origin-hosted repos, Origin is the source of truth. Pushes land on Origin, and GitHub is not in the path.” Pull requests on such a repo stay on Origin and are not mirrored anywhere.

A mirrored repo is a GitHub repository copied into Origin with Sync from GitHub. The mirror docs say mirroring “copies a GitHub repository into Origin and keeps Origin updated as the GitHub repo changes. GitHub stays the source of truth.” A push to the Origin clone URL of a mirrored repo goes to GitHub, and Origin updates after GitHub accepts it. So the mirror is best described as GitHub-to-Origin for code, with a two-way channel for pull request conversation only.

What syncs and what does not

Per the mirror docs, git history, branches and tags are included, along with code you can browse and search on Origin, GitHub pull requests you can review in Cursor, and ongoing updates. GitHub Issues, GitHub Actions workflows and secrets are not included. If you rely on Issues for planning or Actions for CI, those stay where they are. Cursor’s Bugbot docs section, referenced from the mirror page, adds a related note: if you only want automated review comments on GitHub PRs, Bugbot does that without moving storage.

The origin/ branch namespace

The clone, push and pull docs describe a feature built for GitHub outages. On a mirrored repo, branches whose names start with origin/ live only on Origin. They never sync from GitHub and never sync to GitHub, and Origin does not import a GitHub branch named origin or origin/..., so a branch on GitHub cannot overwrite your Origin-only work. The origin push local command writes them by adding a remote called origin-local that points at the /local path of the clone URL. Two limits follow from the docs: an origin/* branch cannot be the head of a GitHub pull request, and /local is enabled per repository, so git may report the repo as not found if it has not been turned on for yours. Git LFS batch requests do not fail over, and a repo that has not finished its first sync still needs GitHub.

This is the practical answer to the outage pitch. It keeps you able to read and to work on a branch while GitHub is unreachable. It does not let you merge into a GitHub-owned default branch, because that branch still lives on GitHub.

Visibility and who can see a synced repo

The launch changelog says anyone with read or write access to a synced repo can view it in Cursor. A Cursor staff reply on the forum clarifies a common stumbling block: a synced repo inherits its visibility from GitHub, so a private GitHub repo arrives as Private and is visible only to the person who synced it plus anyone granted access. Teammates see an empty codebase asking them to pick repos to sync. To share it, the person who synced it, or a repo admin, opens Settings, Permissions and changes visibility to Internal or grants specific people access. That reply is a forum post by Cursor staff, not a docs page, so confirm it in your own account.

Pull requests

Every Origin repo has pull requests. The pull request docs describe four tabs on each one: Activity for the ordered timeline, Commits, Checks for check runs and status on the head commit, and Changes for the diff, where you can comment on lines, leave reviews, or switch to a Tour that uses Code Tours for a guided walkthrough. You can request reviewers, merge when reviews and CI are satisfied, and Origin surfaces merge conflicts so you can resolve them before merging. When a repository’s rules require reviews, a Request Changes review from someone with write access blocks merging until that reviewer approves or someone with write access dismisses it.

To open one from a terminal, push a branch and use the create-pull-request flow from the repo’s Code tab:

git checkout -b my-change
git push -u origin my-change

On mirrored repos the Pull Requests tab shows GitHub pull requests and you can review them in Cursor. The changelog says that comments posted in Cursor appear on GitHub and that reactions or replies on GitHub show up in Cursor within seconds, and that a review assigned to you on GitHub can be reviewed and merged from Cursor. Cursor’s docs say little else about merge methods or branch protection on Origin-hosted repos, apart from the repository rules that require reviews, so check that your required workflow is expressible before you depend on it.

Agents and automations

The pitch for Origin is that the code, the pull request and the agent live in one place. The changelog says you can ask Cursor questions about code you are browsing, and that it can answer, make changes, update PRs or push a branch. The agents docs add detail in three areas.

• Cloud agents can clone, branch, commit and push against Origin repositories. On a repo created on Origin they open Origin pull requests; on a mirrored GitHub repo they open GitHub pull requests. Agents use your Cursor account’s Origin access.
• Automations run cloud agents on a schedule or when source-control events fire. Documented triggers for Origin repos include a push to a branch such as main, pull request opened, pull request pushed and related PR events, and label changes on a pull request.
• Local agents in Cursor can create Origin repos with the CLI: install, sign in, origin repo create, set the remote and push. For other coding agents, origin agent setup installs a skill that tells the agent to read origin agent prompt, a usage guide written for your installed CLI version.

A related change from August 27 removes the need for any forge at the start. Selecting Start from scratch in the cloud agent repo picker lets you prompt an agent with no connected source control; Cursor creates an Origin repo in the background and a Create repo button saves the result with a custom name and Internal or Private visibility. Publishing a live URL from there needs a Vercel account. That is first-party and dated in the changelog, and it is the clearest example of Origin working as the default home for agent output rather than as a GitHub add-on.

One limit to keep in mind: forum users reported at launch that the agent panel did not work on some GitHub-synced repos while it worked on repos created directly on Origin. A Cursor staff member asked for a bug report, and we could not confirm whether it was fixed. Because Cursor’s docs say cloud agents work on mirrored repos too, test agents on a mirrored repo before you assume parity. For how this fits into Cursor’s wider agent work, our guide to running Cursor, Kiro and Codex from your phone covers the remote control side.

Apps and integrations

At launch, the changelog named three integrations: Vercel, Depot and Buildkite, installed from codebase settings and visible on a repo’s Apps tab. Connecting Vercel gives each pull request a preview deployment and ships to production on merge. Depot and Buildkite handle CI: both run your existing GitHub Actions workflows, and Buildkite also runs its native pipelines. The docs list the same three as examples of third-party apps and add that you can create an internal app for your own team to call the API.

On October 13, 2026, Cursor announced the Origin App Marketplace. Its changelog says Origin integrates with over 20 apps from partners including Cloudflare, Linear, Sentry and Socket Security, and that the marketplace is open to public submissions.

To publish an app, Cursor’s steps are: create an app in your namespace (it stays private while you build), build against the Origin API, make it public and submit with a slug, suggested tags and a demo video showing install, uninstall and core flows, then wait for review. We did not test any marketplace app, and listing does not tell you how well an app works.

The Origin API

Origin has a public REST API, documented as early beta and “subject to change.” The reference gives the base URL as https://api.cursor.com/v1/origin and publishes a full Markdown reference plus an OpenAPI 3.1 specification. Apps authenticate with an app JWT signed by a key you generate and exchange it for installation access tokens; there are also user-authenticated CLI requests and Git HTTPS authentication. The reference covers rate limits, pagination and errors, and a section on acting on behalf of users with scopes.

The endpoint groups in the reference index show how much of a forge is already exposed: apps and installations; repositories (list, create, update, delete, branches, tarball and Sync Mirror); check runs, suites and annotations; commits, comparison and contents, including Grep Contents; git data such as blobs, trees and refs; grants; an inbound IP allowlist; labels; rulesets; SSH certificate authorities with a certificate requirement setting; and a long list of pull request endpoints for comments, reviews, reviewers, auto merge, mergeability and search. Webhooks cover repository push, pull request, comment, review, check run and installation events, with signature verification, retries and automatic disable.

One rule affects automation on mirrored repos. The mirrored repositories reference says that on a mirrored repository only five scopes apply (metadata read, members read, contents read, mirror read and mirror sync). Every other scope returns 403, pull requests, reviews, comments, checks and rulesets are rejected, and over Git HTTPS an installation can clone, fetch, pull and download LFS but not push. Changing a mirror’s state, retrying a failed first sync or detaching it, is a user-credential operation rather than something an app installation can do. The API also lists an Origin Migration API, called with a user access token, for moving repositories between GitHub and Origin mirrors. If you build an app, plan for it to be read-mostly on mirrored repos.

Features that appear in the reference, such as IP allowlists, rulesets and SSH certificate authorities, are API reference entries. We did not find a docs page walking through the matching web UI, and we did not test them, so do not assume they are production-ready from the reference alone.

Origin vs GitHub vs GitLab

A comparison needs a caveat up front. The Origin column below comes from Cursor’s docs, fetched October 30, 2026. The GitHub and GitLab columns describe well-known, long-standing capabilities of those products and were not re-fetched for this article, so confirm the details on each vendor’s docs before you rely on them. We left out claims about uptime, speed and price for any vendor because we have no first-party numbers to compare.

Two points deserve emphasis. Origin does not currently support GitLab as a sync source: when a forum user asked, a Cursor staff member replied that there was nothing in the near term. That is a forum answer from August 18, so re-check it before ruling Origin out. And the comparison favors Origin only on one axis, agents sitting in the same surface as the code. On forge maturity, built-in issue tracking, built-in CI and self-hosting, the established forges are ahead of a beta by a wide margin. That is normal for a product in its first months, and it is why the mirror-first model matters. A concise take on the editor side of Cursor’s strategy is in our Cursor vs Antigravity comparison.

How to try it, step by step

The lowest-risk trial uses a throwaway Origin-hosted repo first, then a mirror of a non-critical GitHub repo. Nothing below touches your production repositories.

Step 1: Confirm access

Check that your plan is Premium, Super, Ultra, Teams, Enterprise or an eligible legacy plan. On a Team, confirm you are not on legacy privacy mode and that an admin has not disabled Origin. Access opens in stages, so if cursor.com/codebase does not show a Get Started flow yet, you may be waiting on rollout.

Step 2: Claim a codebase name

Open cursor.com/codebase, select Get Started and follow the setup flow. Because the namespace cannot be changed during the beta, do not claim something temporary on a team account. If you only want to experiment, a personal account avoids committing the team’s name.

Step 3: Install the CLI and sign in

The CLI docs give a one-line installer for macOS, Linux and Windows under WSL, and a PowerShell installer for native Windows:

# macOS, Linux, Windows (WSL)
curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin --version
origin auth login

# Windows (PowerShell)
irm https://downloads.cursor.com/origin/install.ps1 | iex

The installer puts origin in ~/.local/bin, so if your shell says command not found, add that directory to PATH. Piping a script from the network to a shell is a normal pattern but worth a glance first; read the script, or use the repo-creation UI and plain git if you prefer to avoid the CLI. Signing in opens a browser flow and sets up the git credential helper.

Step 4: Create a throwaway repo and push

In the UI, select New, enter a name, choose Internal or Private if the repo is team-owned (personal repos are always Private), and create it. Or use the CLI, then push an existing project:

origin repo create my-origin-test
git remote add origin https://origin.cursor.com/{owner}/my-origin-test.git
git push -u origin main

Over SSH, register a public key with origin ssh-key add and compare the host key fingerprint your SSH client prints on first connect against the one on the git docs page before you answer yes. The docs say a mismatch, or a changed-host-key warning with no announced rotation, means the connection is not reaching Origin and you should stop.

Step 5: Open a pull request and let an agent work on it

Push a branch, open a pull request from the Code tab, and try the Changes tab’s Tour view. Then attach a cloud agent to the repo from the Codebase tab and ask it to make a small change or answer a question about the code. Note which tasks it handles cleanly and what it costs in usage, since agent runs draw on your plan’s pool or on pay-per-use models.

Step 6: Mirror a non-critical GitHub repo

From cursor.com/codebase choose Sync from GitHub, pick the org and repository, and confirm. You need the Cursor GitHub app on that org and GitHub admin rights on the repo. When the sync finishes, check Settings, General for sync status, and confirm what a teammate sees (see the visibility note above). Compare the Origin copy’s branches against GitHub, and test whether the agent flow and the app integrations you care about work on the mirror, because the docs say those agents open GitHub pull requests there.

Step 7: Connect one app, then decide

Install a single app from codebase settings, for example Vercel or Buildkite, and check what happens on a pull request. If you do not rely on Origin after a week, nothing needs unwinding: detach a mirror from Settings, General (the GitHub repo is not affected), and delete throwaway repos with origin repo delete org/name. The one piece that sticks is the claimed namespace.

Risks and open questions

Origin is young, and several questions that matter to a team lead are not answered in Cursor’s docs. Press coverage at launch raised some of them. These are press and community statements, labeled as such.

• Data handling. The only data statement we found in the docs is that Origin follows the namespace owner’s Privacy Mode. VentureBeat wrote on launch day that retention, residency, training use and subprocessor terms for Origin were unpublished. A Cursor staff member answered a forum question on privacy by pointing to Privacy Mode and adding it to the docs. If you handle regulated code, ask Cursor for written terms before storing it.
• Default-on for some orgs. The changelog says Origin is rolling out to all paid plan users “except enterprise orgs whose admins opt out.” VentureBeat pointed out that this reads as opt-out. Whether or not you plan to use Origin, an admin should decide the org’s posture deliberately.
• Feature gaps. No GitLab sync (a forum answer, August 18). Submodules work for push and sync, but a staff reply on August 30 listed gaps: the web browser cannot click into a submodule, PR review shows a placeholder for submodule updates, and cloud agents do not automatically pull submodule contents.
• Reliability. Cursor has published no uptime or SLA figures for Origin that we found. Press noted that GitHub had a long incident on launch day; that coincidence says nothing about Origin’s own availability. The InfoQ write-up, like the changelog, describes a narrow early feature set.
• Lock-in. The namespace is fixed during the beta, and Origin-native repos use standard git, which makes a git clone the practical exit. Pull request history on Origin-hosted repos is not described as exportable in the docs we read.
• Ownership. VentureBeat reported that Cursor now operates inside SpaceX’s SpaceXAI division, and the pricing page says subscriptions are sold by X Subscription Corp. We cite this as context from the press and the pricing page; we have not verified corporate terms, and we make no claim about how it affects data handling.

Who should try it

Teams already paying for AI coding usage elsewhere may find the comparison with other vendors’ billing models useful context; our GitHub Copilot AI credits guide explains how GitHub’s own usage billing works, and the Grok and SpaceXAI side of Cursor’s models is covered in our Grok 4.5 and Cursor launch article.

Limitations of this guide

• We read Cursor’s pages on October 30, 2026 but did not use Origin, so everything about behavior is as documented, not as tested.
• Cursor’s Origin docs are labeled early beta and say screens and controls may change, so plan access and feature lists can move.
• We found no first-party performance, uptime, storage limit, repo size limit or Origin-specific price, and report none.
• The GitHub and GitLab columns in the comparison table were not re-fetched. Use vendor docs for any decision.
• Forum replies from Cursor staff are used for visibility, GitLab and submodule details. They are real first-party statements but are not part of the formal docs.
• The June 16 pre-announcement and the planned August 11 launch come from one trade site and a LinkedIn repost and are unverified.
• The Origin API reference lists IP allowlists, rulesets and SSH certificate authorities; we did not verify matching UI or test any endpoint.

Verdict

Origin is a credible beta forge with one distinctive idea: the repo, the review and the agent share a surface, and agents can start from nothing and land in an Origin repo with no third-party source control at all. For a Cursor Premium-or-higher user, trying an Origin-hosted repo takes minutes and is easy to unwind. For a team on GitHub, mirroring is a low-commitment way to see whether review in Cursor is better, because the mirror leaves GitHub in charge.

It is not yet a GitHub replacement on features, and the unpublished data terms are the item to settle before sensitive code goes in. Treat it as an experiment with a clear exit: detach a mirror, delete a test repo, keep git as your safety net. Re-check the docs in a month, because Cursor said agent-native features were still to come.

FAQ

Sources

Sources checked October 30, 2026.

• Origin Code Hosting: Cursor changelog, dated August 17, 2026 (launch, repos, GitHub sync, PRs, apps, rollout scope)
• Cursor changelog feed: Origin App Marketplace (October 13, 2026) and Start from scratch (August 27, 2026)
• Origin docs overview, Clone, push and pull, Mirror a GitHub repository, Create a repository, Install the CLI, Pull requests, Agents and automations and Codebase settings
• Cursor Origin API and Mirrored repositories reference
• cursor.com/origin and Cursor pricing (plan grid as of October 30, 2026)
• Origin Code Hosting, Cursor community forum: staff announcement and replies (August 17 to 30, 2026)
• Press, labeled as press: VentureBeat, August 17, 2026 and InfoQ, August 2026

Related reading: Cursor pricing and X subscription plans, Cursor vs Antigravity, code from your phone with Cursor, Kiro and Codex and GitHub Copilot AI credits guide.