Cursor builds Origin to host code from fleets of AI agents, launching today

Cursor launched Origin on August 11th, a Git platform designed to host code produced by fleets of AI agents, extending the company's reach from agent assignment to code merging. The product, introduced by CEO Michael Truell on June 16th, was initially limited to a work-email waitlist and is led by Tomas Reimers, co-founder of Graphite, which Cursor acquired in December 2025. Origin claims throughput of 22.6 commits per second in one repository, though Cursor has not published benchmark methodology or production results.

Michael Truell @mntruell https://x.com/mntruell , Cursor's co-founder and CEO, introduced Origin on June 16th as a Git platform built to handle code produced by teams of AI agents. Cursor is set to launch Origin on August 11th after initially limiting the product to a work-email waitlist. The launch extends Cursor's reach across the full path from assigning work to an agent through writing, testing, reviewing, storing and merging the resulting code. Origin adds repository hosting to a product line that already includes an agent-first editor, cloud execution, automated pull-request review, workflow automation and an SDK for building custom agents. Tomas Reimers, a co-founder of code-review developer Graphite, is leading Origin inside Cursor. Cursor agreed to acquire Graphite https://cursor.com/blog/graphite in December 2025 after identifying review and safe merging as the next bottlenecks created by faster code generation. Reimers had originally built Graphite with co-founders Merrill Lutsky and Greg Foster as an internal tool for keeping engineers unblocked before turning it into a code-review product. At Cursor's Compile conference https://cursor.com/compile , Reimers presented Origin as a new Git platform for teams and agents. Coverage of the demonstration reported a Git-compatible service with agent-facing APIs, Model Context Protocol support, automated responses to merge conflicts and failed continuous-integration runs, and infrastructure designed for many agents pushing changes in parallel. Cursor's demonstration claimed throughput of 22.6 commits per second in one repository, but Cursor has not published a benchmark methodology or production results for that figure. That number describes repository ingest, not software quality. A forge can accept thousands of agent commits without establishing whether those changes are correct, secure or worth merging. Cursor's larger product strategy addresses that gap by placing automated review and policy controls around the agents that generate the code. Origin is a Git host, not a replacement for Git Origin is best understood as a forge: the service around Git that stores repositories and manages collaboration, pull requests, permissions, checks and merges. Git remains the underlying version-control system. Origin is positioned against the repository and collaboration layer occupied by GitHub and GitLab. The distinction matters for portability. Standard Git history, branches and tags can generally move between compatible hosts. Pull-request discussions, issue trackers, access policies, CI configurations and application integrations are host-specific. Any serious Origin evaluation will therefore depend on Cursor's import tools, identity controls and compatibility with existing development pipelines. Ahead of the August 11th launch, Cursor had not published Origin's pricing, security architecture, data-handling terms or migration tooling, and the public product page continued to offer only a work-email waitlist. Cursor had said around the June announcement that Origin was expected in fall 2026, making the August launch earlier than its initial public timeline. What an agentic Cursor team can use today Origin is one layer in a stack Cursor has assembled throughout 2026. Teams do not need Origin to begin running agents in parallel, although their repositories and pull requests can remain on an existing host. Cursor 3 https://cursor.com/blog/cursor-3 , released on April 2nd, introduced a workspace that puts local and cloud agents in one interface. Agents started from desktop, web, mobile, Slack, GitHub or Linear can appear together, and a task can move between a local machine and Cursor's cloud. Worktrees isolate simultaneous changes on separate branches, while multi-root workspaces let one agent modify several repositories in a single session. Cursor also supports asynchronous subagents https://cursor.com/changelog/2-5 . A parent agent can split work into narrower jobs with separate context, models and tool permissions. The /multitask workflow can break a larger request into parallel streams, while nested subagents can delegate further. This is Cursor's closest current implementation of an agent team: a human or parent agent decomposes the work, specialized agents execute it, and their outputs return for integration and review. Cloud agents https://cursor.com/blog/cloud-agent-lessons run in dedicated virtual machines with their own dependencies and network access. They can continue after a developer closes a laptop and return artifacts such as logs, screenshots and demonstrations. That changes the operator's job from watching every tool call to specifying the task, defining acceptance criteria and checking the result. Truell wrote in February that 35% of pull requests merged inside Cursor were created by agents running autonomously in cloud virtual machines. That is a Cursor-reported internal metric, but it explains the timing behind Origin: Cursor is already experiencing the review, environment and coordination problems that appear when agent output becomes a meaningful share of production work. Rules, automations and custom agents form the operating layer Cursor's team product turns individual prompting habits into shared infrastructure. The current Teams plan https://cursor.com/pricing starts at $40 per user per month and includes a private team marketplace for distributing rules, skills and plugins. Teams can encode repository conventions, testing requirements and recurring workflows instead of asking every engineer to configure agents independently. Automations https://cursor.com/changelog/03-05-26 create always-on agents triggered by schedules or events from services including GitHub, Linear, Slack, PagerDuty and webhooks. Each run starts a cloud sandbox and follows the configured instructions, model choices and MCP connections. Appropriate jobs include triaging bug reports, investigating failed builds, updating dependencies and preparing routine pull requests. For workflows that need application logic, the public-beta Cursor SDK https://cursor.com/changelog/sdk-release exposes the same agent runtime used across Cursor's desktop, CLI and web products. Developers can launch local or cloud agents from TypeScript or Python, stream their work and incorporate them into CI systems or internal tools. June updates added custom tools, configurable state stores, nested subagents and an auto-review layer that can hold risky tool calls for approval. The review layer is Bugbot https://cursor.com/blog/may-2026-bugbot-changes , Cursor's usage-priced pull-request reviewer. Teams can set review effort and connect additional context through MCP. Cursor says Bugbot can learn review rules from reactions and human comments, creating a feedback loop between a team's standards and future automated reviews. Those performance and resolution figures remain Cursor's own measurements. Governance becomes the limiting factor Running several agents is straightforward. Giving them production credentials, network access and permission to merge code is the harder organizational decision. Cursor Enterprise now supports organizations, teams and groups https://cursor.com/blog/organizations with different budgets, approved models and agent permissions. Administrators can separate experimental users from production teams, restrict repository and MCP access, apply network policies, control command execution and inspect usage. Cursor's auto-review mode also routes uncertain shell, MCP and fetch operations through a classifier before allowing execution or requesting human approval. A workable agentic team therefore needs explicit boundaries: isolated branches or worktrees, reproducible environments, written acceptance criteria, restricted credentials, deterministic tests and human ownership of final merges. Parallel agents increase output and can also multiply flaky tests, conflicting changes and unnecessary pull requests. Origin is Cursor's proposed answer to the coordination pressure created by that output. Its strategic value will depend on review quality, policy enforcement and migration support rather than raw commit throughput. The August 11th launch shifts the immediate question from when Origin will arrive to whether Cursor can provide the operating details and compatibility that engineering teams need before moving their system of record.