Cursor Origin
Agent-Scale Git: Why Code Hosting Is Being Rebuilt
Agent-scale git means hosting and review built for code written by many agents at once, not one engineer opening one pull request at a time. The throughput shifts the bottleneck from writing code to reviewing and merging it, which is the problem Cursor Origin is aimed at.
On this page
What does "agent-scale" mean for Git hosting?
Git itself does not care whether a commit came from a person or an agent. The tools built around git do. Pull requests, review queues, CI runs and merge rules all assume a human cadence: you finish a change, open one request, wait for a teammate, then merge. That rhythm is the thing agents break.
When a team runs several agents at once, each one can finish a task and open a change while you are still reading the last one. The work piles up at review and merge, not at writing. Agent-scale is shorthand for hosting that expects that pile-up and is built to clear it.
Why does agent throughput strain GitHub-style workflows?
The strain shows up in a few familiar places, and they compound. The table names each one and what it looks like when agents, not people, are the ones generating the work.
- Pressure point
- Review
- Human pace
- A few PRs a day per person
- Agent pace
- Many PRs an hour, often touching the same files
- Pressure point
- Merge conflicts
- Human pace
- Occasional, you remember the context
- Agent pace
- Frequent, across changes you didn't write
- Pressure point
- CI
- Human pace
- Runs you watch and rerun by hand
- Agent pace
- A queue that has to clear itself
- Pressure point
- Branches
- Human pace
- A handful in flight
- Agent pace
- One per task, many at once
| Pressure point | Human pace | Agent pace |
|---|---|---|
| Review | A few PRs a day per person | Many PRs an hour, often touching the same files |
| Merge conflicts | Occasional, you remember the context | Frequent, across changes you didn't write |
| CI | Runs you watch and rerun by hand | A queue that has to clear itself |
| Branches | A handful in flight | One per task, many at once |
None of these are new problems. Agents make them constant instead of occasional.
The review column is the one that hurts first. A model can write a correct change in a minute, but a person still reads it at human speed, and there is now a queue of them. Most attempts to fix this either make changes smaller and easier to review, or push more of the first-pass review onto bots.
What is Cursor's bet with Origin?
Cursor's framing is that the hosting layer itself should be rebuilt for this, not patched. The confirmed part is the intent: a git forge for the agent era, with the line that code is "moving faster than any infrastructure was built to handle." The mechanism is where confirmed runs out.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The shift Origin is designed around. The right column is the workload agents create.
Reported figures like commits per second, clones per hour and millisecond failover came from coverage of the demo, not a Cursor engineering post. At least one widely shared throughput stat was later traced to a different product. Wait for first-party numbers before you plan around them.
How should teams handle agent-scale work today?
You do not need Origin to feel this problem, or to start managing it. The moves that help are ones you can make on GitHub or GitLab right now, with Cursor features that already ship.
- 1Give each parallel agent its own worktree so two agents editing nearby files don't collide. The /worktree command sets one up.
- 2Keep changes small. Smaller diffs review faster, which is the real bottleneck once agents are writing.
- 3Put a bot on the first pass. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. reviews pull requests and Auto-review can gate risky changes before a human reads them.
- 4Treat the merge as the moment to slow down, not speed up. Throughput is worth nothing if you merge a change no one understood.
Faster code generation does not mean faster shipping on its own. It just moves the queue. The teams that get value from agents are the ones that fixed review and merge, not the ones that generated the most diffs.
Frequently asked questions
Do I need Cursor Origin to run agents at scale?
No. The throughput problem is real today, but the tools that help, worktrees for isolation, small changes, and bots like Bugbot on the first review pass, all work on GitHub and GitLab now. Origin is one bet on solving it at the hosting layer, not a prerequisite.
What actually slows down when agents write most of the code?
Review and merge. A model can produce a correct change quickly, but a person still reads it at human speed, and parallel agents create a queue of them plus more frequent merge conflicts. The bottleneck moves off writing and onto everything after it.
Are Origin's performance numbers real?
They are unverified. The commits-per-second and failover figures come from press coverage of the Compile demo, not a Cursor source, and some were misattributed to other systems. Treat them as claims until Cursor publishes production numbers.
Sources & last verified
Cursor ships frequently. Facts verified against primary sources on June 26, 2026.