Cursor now wants to host your code, not only write it. On August 17, 2026, the company began rolling out Origin, its own git hosting service, in early beta on all paid plans. Repos, pull requests, code browsing, and two-way GitHub sync shipped on day one, all living in a new Codebase tab inside the editor.
The pitch is blunt: git forges were designed for humans pushing commits a few times a day, and Cursor is betting the next decade of version control gets shaped by agents opening branches, updating PRs, and merging work around the clock. Origin is the first hosting platform designed around that assumption from the start.
If your team builds APIs, this touches you sooner than you might think: your OpenAPI specs, your CI-driven contract tests, and your review workflow all live wherever your git remote points. Here’s what Origin does today, what it’s missing, and how to keep an API workflow (including Apidog test automation) intact if you try it.
What Origin is
Origin is a cloud git forge operated by Cursor. The initial beta includes:
- Hosted repositories you create from the Codebase tab, from the web at
cursor.com/codebase, or from a Cursor agent mid-task. Remotes follow the patternhttps://cursor.com/codebase/{owner}/{repo}, and standardgit clone,push, andpullwork against them. - Pull requests with the parts you’d expect: a timeline, commits, checks, diffs, comments, and merging, reviewable inside the editor or in the browser.
- Code browsing and search on the web, with repo-level and codebase-level settings.
- A dedicated CLI for terminal workflows, separate from the editor.
- Agent integration, which is the actual point: agents can read the codebase, answer questions about it, make changes, update PRs, and push branches from the same surface where you review their work. Per the changelog, more “agent-native features ship soon.”
Availability: Pro, Teams, and Enterprise plans only. Free-plan users can’t create Origin repos, and enterprise orgs can opt out entirely. Details like storage quotas, a public API, and webhooks aren’t documented yet, which is worth remembering before you move anything important. See Cursor’s Origin docs for the current state.
Origin caps a busy month for the company; press coverage, including SiliconANGLE’s report, also notes the launch landed days after SpaceX completed its acquisition of Cursor. For a refresher on the editor side of the product, our everything-you-need-to-know Cursor guide covers the fundamentals.
The GitHub sync is the clever part
Nobody migrates a company off GitHub in a weekend, and Cursor knows it. So Origin’s beta leans on a bidirectional sync instead of a migration:
- Mirror a GitHub repo into Origin and synced repos update in real time.
- PR comments and reactions sync both ways within seconds: a comment left in Cursor posts to GitHub, and a GitHub reply shows up in Cursor.
- GitHub stays the source of truth for any repo that started there. Pushes keep flowing to GitHub; Origin is a live mirror with a nicer agent story, not a replacement remote.
- Access permissions mirror your GitHub read/write settings, so the sync doesn’t quietly widen who can touch a repo.
This is the same low-commitment adoption pattern that worked for Cursor against VS Code: don’t ask anyone to leave, sit alongside the incumbent, and let the new workflow win on convenience. You can try Origin’s PR review UI on Monday without telling your platform team, because nothing about your GitHub setup changes.
The strategic subtext is harder to ignore. GitHub has been the default home of code for fifteen years, and its own AI story runs through Copilot, which competes directly with Cursor; we compared the two in Cursor vs GitHub Copilot. Cursor building its own forge is a statement that it no longer wants its agent roadmap gated by a competitor’s platform.
What’s missing (and it’s a lot, for now)
The beta is a forge, not a full DevOps platform. As of launch, Origin has:
- No native CI/CD. Instead, Depot and Buildkite connect through a repo’s Apps tab and can run your existing GitHub Actions workflow files against Origin repos. It’s a pragmatic bridge, but it’s a third-party dependency where GitHub has a built-in product.
- No issues, no discussions, no wiki. Code review is the only collaboration primitive.
- No self-hosting, no documented public API, no webhooks, no stated storage limits.
- One notable launch partner: connect Vercel from the Apps tab and every PR gets a preview deployment that ships to production on merge, the same flow Vercel runs for GitHub repos. (Vercel has been shipping fast lately; it’s the same Gateway currently running the GPT-5.6 Sol discount.)
None of these gaps matter much while GitHub remains the source of truth behind the sync. They matter enormously the day a team considers making Origin primary. Treat the beta as a review-and-agents layer, not as infrastructure.
What this means for API teams specifically
Your API workflow probably touches the forge in three places: the spec lives in the repo, contract tests run in CI on every PR, and reviewers approve changes to both. Here’s how each maps to Origin today.
Specs and design review. If you follow a design-first workflow, your OpenAPI file is the most-reviewed artifact in the repo. Origin’s PR diffs handle YAML like any other text, and the two-way comment sync means an API reviewer living in GitHub and an agent operator living in Cursor see the same thread. Nothing breaks, nothing improves yet either; the interesting part arrives when agents start proposing spec changes as PRs, which is exactly the loop Origin is built for. Our guide to running Apidog CLI inside Cursor already covers letting the editor’s agent validate a spec before it commits.
CI contract testing. Apidog CLI runs as a step in any CI system, and Origin’s answer to CI is “bring your GitHub Actions workflows via Depot or Buildkite.” In practice that means an existing workflow step like apidog run --scenario smoke-tests should carry over unmodified, because the workflow file format is the same. The honest caveat: we haven’t verified Depot’s Actions compatibility layer against every action in the wild, and neither has anyone else this week. Run your pipeline against a mirrored throwaway repo before trusting it with a release branch.
Agent-driven changes need agent-proof gates. The whole premise of Origin is more code arriving from agents, faster. That raises the value of automated, deterministic checks on every PR, because human reviewers become the bottleneck. A contract test suite that fails the build when a response schema drifts is precisely the kind of gate that scales with agent throughput, and it’s a five-minute setup in Apidog: define assertions against your spec once, run them from CLI in whatever CI executes your Origin PRs. Download Apidog if you want that gate in place before your agents get push access, and see our QA testing with Cursor walkthrough for the broader testing loop.
Should you try it?
A decision shortcut:
- Solo devs and small teams on Cursor paid plans: yes, low risk. Mirror a repo, use the PR view, keep GitHub as truth. You lose nothing if Origin doesn’t stick.
- Teams with heavy GitHub Actions investment: try it on a side project first. Your workflows theoretically port via Depot or Buildkite, but “theoretically ports” is not a migration plan.
- Anyone whose compliance story names GitHub: wait. No self-hosting, no documented API, and an early beta label make Origin a nonstarter for regulated code today.
- Teams already running Cursor agents in anger: this is who Origin is for. If you’re using Cursor’s agent features daily, having agents open and update PRs on a forge that treats them as first-class users is a real workflow gain right now.
The forge is becoming an agent surface
The real story isn’t that GitHub has a new competitor. It’s that Cursor thinks the repository itself is about to become primarily an interface for agents, with humans reviewing rather than authoring most changes. Whether or not Origin wins, every forge will be pulled in that direction, and API teams will feel it first, because specs and contract tests are the most automatable review gates in software.
The preparation is the same either way: get your API checks scriptable and forge-agnostic. Apidog keeps your specs, mocks, and test scenarios in one place and runs them from a CLI that doesn’t care whether the PR came from a human on GitHub or an agent on Origin. Try it free, and your review gates move with you no matter who wins the forge war.
FAQ
Is Cursor Origin free? No. Origin code storage requires a paid Cursor plan (Pro, Teams, or Enterprise). Free-plan users can’t create Origin repos, and enterprise orgs can opt out of Origin entirely.
Do I have to leave GitHub to use it? No. The launch design assumes you won’t: mirror a GitHub repo into Origin and GitHub remains the source of truth, with pushes, PR comments, and reactions syncing both ways in near real time.
Does Origin have CI/CD? Not natively. Depot and Buildkite connect via the Apps tab and run your existing GitHub Actions workflow files. Vercel is also integrated for PR preview deployments.
Can agents use Origin directly? Yes, that’s the core feature: Cursor agents can create repos, answer questions about the codebase, update pull requests, and push branches. Cursor says more agent-native features are coming; our Cursor agent mode guide covers what agents can already do in the editor.
How do I run API tests on Origin pull requests? The same way you do on GitHub: run Apidog CLI as a CI step. On Origin that means wiring Depot or Buildkite to the repo and reusing your existing Actions workflow, with your apidog run commands unchanged.
