On August 17, 2026, Cursor began rolling out an early beta of its Git hosting platform "Origin" to paid plans. Until now, Cursor has been the place where code gets written and agents run; now it's stepping into the role of storing Git repositories and handling pull requests (PRs) as well. The goal isn't Git compatibility for its own sake. What's being tested in this early beta is whether the round trip of an agent reading code, making changes, receiving checks, and updating a PR can all be connected within Cursor itself.
However, this is neither a finished product nor a general release. Free is excluded, and even for Pro, Teams, and Enterprise, access is being rolled out gradually, so being on an eligible plan doesn't guarantee immediate access. For Enterprise, administrators can opt out, and Cursor states it will offer "agent-native features" going forward.
Code Hosting Rolled Out Gradually to Paid Plans
With Origin, you can create repositories and clone, push, and pull them using standard Git. It supports code browsing and search, PR creation, review, and merging, and can be shared within a team. Existing GitHub repositories can be brought in as mirrors, which is designed to let teams try it out without immediately switching their primary storage location.
Cursor Agent can newly create Origin repositories. For existing Origin repositories, Cloud Agent can clone them, cut a branch, commit and push changes, and open a PR. Automations can trigger Cloud Agent based on push or PR events. Beyond Vercel, integrations with Depot and Buildkite are also available.
However, Depot and Buildkite only target Origin-native repositories. CI for GitHub mirrors remains on the GitHub side, so the core of this initial offering is code storage and browsing, PR handling, and GitHub sync. Not all agent-oriented features are yet in place.
Operations Available via the API and Stacked PRs
For Origin-native repositories, there's a REST API with https://api.cursor.com/v1/origin as the base URL. It can read and write repositories and commits, and update checks and PRs. App installation is also handled via the API, and Cursor has published an llms.txt for agents. Origin Apps sign short-lived JWTs with an Ed25519 key, which are then exchanged for installation access tokens. Tokens for Git HTTPS expire after at most 15 minutes.
Permissions are divided by use case, spanning code content, PRs, reviews, and checks. The default limit for installation access tokens is 3,000 points per minute, while App JWTs and user/team service-account API keys are limited to 600 points per minute. Most reads consume 1 point, typical writes consume 5 points, and repository creation and PR merges consume 10 points — meaning that simply adding more agents doesn't grant unlimited operations.
Because the API and Git operations can share the same short-lived tokens, an app can clone only the repositories it's authorized for, then push changes and update PRs or checks. Short-lived tokens with fine-grained scopes are designed to avoid granting permanently broad permissions to agents that run continuously.
The PR creation API accepts a parentPullNumber, allowing dependent changes to be chained together as stacked PRs. The merge API merges everything from the root of the stack up to a specified PR in one go. This lets you split review units finely while still merging them in order — though this feature is limited to Origin-native repositories.
Webhooks are delivered using an at-least-once model, which can result in duplicates, and retries occur up to 6 times on connection errors, 429s, and 5xxs. The backoff starts at 30 seconds and extends through 1 minute, 2 minutes, and 4 minutes, up to a maximum of 8 minutes. On the other hand, push webhooks don't include a complete commit list, and there's no dedicated thread/resolution API for PR comment thread IDs. Anyone building automation on top of this needs to design around these gaps.
GitHub Mirrors Serve as a Migration Path, with GitHub Remaining the Source of Truth
GitHub mirrors continuously sync everything from Git history to branches and tags. Code can be browsed and searched in Origin, and PRs sync bidirectionally. However, GitHub Issues, GitHub Actions workflows, and secrets are not synced. Pushes to the mirror pass through to GitHub, and GitHub remains the source of truth.
Because of this separation, existing projects can try Origin without changing their primary storage location. That said, this doesn't mean Origin has replaced GitHub. Mirrors from GitHub cannot have Origin Apps installed, and specifying one via the API returns a 403. Webhooks also aren't sent, and the PR merge API rejects mirrors. During the mirror stage, operations delegated to agents and CI remain on the GitHub side.
Detaching the mirror makes Origin the source of truth, but this doesn't affect the repository on GitHub's side. Whether to migrate isn't determined by Git sync alone — teams also need to decide where to place Issues and CI operations, and rebuild the scope of what apps are allowed to operate on.
Over 70,000 Conflicts Is Not a Performance Metric for Origin
In a separately published experiment on a group of agents, Cursor found that the old harness generated over 70,000 merge conflicts before it was stopped. With the new harness, the total across 4 hours came in under 1,000; in the old experiment, the most congested file saw 1,173 agents cause 7,771 conflicts. In the new experiment, the maximum for a single file was 47.
This figure is not a benchmark for Origin, nor does it demonstrate Origin's ability to automatically resolve conflicts. Still, it does show that when running parallel agents, the bottleneck often isn't generating code but rather how changes to the same repository get divided, reviewed, and integrated. Origin's stacked PRs and permission scopes are meant to support this kind of coordination work. Short-lived tokens and event retries also form part of the foundation for running agents safely.
Can Unified Operations Make a Difference Against GitHub's Scale?
GitHub had over 180 million developers in 2025, with a monthly average of 43.2 million PRs merged. Commits reached nearly 1 billion for the year, code pushes averaged 82.19 million per month, and August 2025 alone saw roughly 100 million commits. GitHub itself, in April 2026, rolled out a feature to paid plans where the Copilot cloud agent works on a branch without immediately opening a PR, letting users review the diff before proceeding to a PR. Simply "supporting agents" won't be enough to differentiate Origin.
What's being tested for Cursor is whether running hosting and Cursor Agent as one unified system can make review and integration easier to handle than existing GitHub-centric workflows. Cursor hasn't disclosed throughput figures or service-level guarantees for this early beta under heavy parallel load. Beyond just the pace of adoption, what needs to be verified is the scope of native integration, its stability, and whether teams can actually manage permissions and changes.