On August 17, GitHub experienced widespread service disruptions, and on the same day, Cursor opened its Origin early beta to paying users. Code repositories are now being integrated with continuously running Agents, but existing collaboration infrastructure was designed for human work rhythms. Research shows that 40.2% of repositories have overlapping Agent PRs, with a merge conflict rate of 41.7%. Cursor Origin is designed for high-frequency Agent writes, supporting up to 22.6 commits per second per repository, and integrates repositories, PRs, checks, and reviews. Origin is positioned as a control layer above Git, reimagining high-frequency Agent collaboration workflows. Elon Musk’s xAI, X, SpaceX, and Cursor have formed a complete AI production chain: Colossus provides compute power, Grok provides models, Cursor executes code, and Origin manages engineering state. GitHub is expanding from human collaboration to Agent collaboration, while Cursor has redesigned its forge around Agent workloads—two paths increasingly competing with each other.

Author and source: Leiphone

The owner of the code repository is transitioning from a human to an Agent.

On August 17, GitHub experienced widespread service disruptions. Core services including Web, API, Actions, Pull Requests, Git Operations, and Webhooks were progressively affected, with Web and API error rates approaching 20% during certain periods.

Around the same time, Cursor began gradually rolling out Origin early beta to all paid plans. Repositories, PRs, checks, reviews, merges, and Automations are now being unified under a single system, with Cursor clearly positioning itself: code hosting is now being designed for “agent scale.”

Interestingly, both of these events happened to occur at the same time,恰好放大了一个变化：代码仓库正在接入越来越多持续运行的 Agent，而现有软件协作基础设施，长期适应的是人的工作节奏。

A human might write code for hours and produce only a few commits; an agent can modify, push, trigger checks, and proceed to the next round within minutes. Faster commits are just the surface—the deeper change is that the entire software production system’s timeline is being compressed.

Many new issues GitHub faces, and many problems Origin wants to solve, may begin here.

01 GitHub did not suddenly get old

When GitHub was created, the fundamental unit of software collaboration was a person.

An engineer writes code for a few hours and makes one commit; a feature takes days to develop and becomes a PR; reviews may appear half an hour later or the next day; CI runs taking a few minutes are usually acceptable, and resolving merge conflicts a bit later won’t render the entire system meaningless.

Around this rhythm, GitHub established Pull Requests, Issues, Reviews, Actions, Webhooks, and a permissions system. Even in projects like the Linux Kernel, which maintain consistently high commit volumes, this rhythm still operates on a distinctly human timescale.

According to LWN, the entire development cycle of Linux 7.0 included 14,251 non-merge commits from 2,362 developers. These commits occurred over a multi-week development cycle, involving email discussions, maintainer reviews, subsystem integration, and the release cycle.

Cursor demonstrated a different workload in the June Origin release demo: 22.6 commits/s in a single repository.

This number is from a live demo dataset and is not a production benchmark independently reproduced; it does not prove that Origin can sustain equivalent throughput in real-world business scenarios. However, it sufficiently illustrates the type of workload Origin is designed for: numerous agents continuously writing to the same code state.

Human developers naturally have rate limits. Thinking, writing code, attending meetings, and resting create significant gaps between commits, so a forge designed around humans can shift much of the system load to be absorbed by time.

The agent does not have this restriction.

Dozens of agents can simultaneously fork from the same base SHA, modify related files around the same time, then push together, open PRs, trigger checks, read reviews, modify code, and push again. A single commit may further trigger index updates, permission checks, webhooks, CI, code scanning, review status refreshes, and mergeability calculations.

Therefore, what needs to absorb the change is not the Git object model itself, but more critically, the forge control plane atop Git: APIs, authentication, background tasks, CI scheduling, webhooks, branch protection, review states, merge queues, and the cascading loads formed between these components.

A July study on Agent PRs on GitHub has observed this concurrent pattern. The study analyzed 33,596 Agent PRs across 2,807 repositories, finding that 40.2% of repositories had overlapping Agent PRs in time.

In concurrently modified samples with replay, the text merge conflict rate across Agent PRs is 41.7%, while for concurrent PRs generated by the same Agent, it is 19.8%.

Multi-agent collaboration therefore introduces new concurrency control challenges. GitHub’s recent outage does not prove that agent traffic has overwhelmed existing infrastructure, but it does provide a valuable observation window: when software production shifts from low-frequency human events to high-frequency machine events, capacity planning, queue design, state propagation, and consistency models face an entirely different class of workloads.

The design of Origin also begins here.

02 Origin Rewrite Collaboration Cost

If Origin merely adds a Git repository hosting entry point, it will struggle to disrupt the developer relationships, open-source ecosystem, enterprise permission systems, and toolchains that GitHub has already established.

Its opportunity comes from the agent changing the cost of collaboration. Stacked PR is a typical example.

Human developers typically prefer to organize a feature into a relatively complete PR. Each time a PR is split out, it adds more context, another round of review, and a set of branch dependencies. If a single change is split into dozens of PRs, people can easily spend excessive effort maintaining these relationships.

The cost structure of the Agent differs. When a modification spans dozens of files, any failure may require the Agent to re-understand a broad context. By breaking it into smaller change sets, modifications to schema, service, UI, etc., can form clear dependencies, with each node verified independently, so failures only require addressing the relevant parts.

A small PR can therefore serve as a checkpoint for an Agent, enabling local validation, local retry, and dependency tracking capabilities.

Cursor's acquisition of Graphite can also be understood in this context. Origin's current early beta has not yet fully adopted Graphite's stacked workflow, but Graphite's long-term investments in stacked PRs and stack-aware merge queues directly address the subsequent bottlenecks that arise after Agent increases code generation speed.

After the number of PRs increases, the responsibilities of the merge queue also become heavier. Agent A and Agent B can work simultaneously from the same base SHA, with each passing their respective tests.

After A enters main, B's test results can only prove that the code is valid in the previous state, not that it remains safe after entering the new main. Therefore, the queue must rebuild candidate states based on the evolving main, re-execute checks, and handle dependencies between PRs.

Conflicts can also gradually evolve from manual interruptions into recoverable failure states within the pipeline. Cursor already provides capabilities such as /babysit, which continuously handle PR feedback, failed checks, and conflicts. When a candidate merge encounters issues, the relevant context can be reassigned to an Agent to correct and revalidate it in an isolated environment.

Reviews will also become structured. Human collaboration relies heavily on natural language and team experience, while long-running agents require clear identification of which checks failed, which threads remain unresolved, which policies were not met, and what the current head SHA is.

Origin has exposed via API the repository, commit, checks, PR, and other objects, distinguishing between formal reviews and regular discussions.

These structured states can then be directly consumed by Automations. Push, PR opened, or PR pushed triggers the cloud agent, with execution results written back to checks and PRs; failures enter the handling process. MCP, hooks, and Agent API allow external tools to join the same event chain.

“Detach from GitHub” addresses the migration path. Teams can first mirror the GitHub repository, keeping GitHub as the source of truth, while migrating the Agent workflows to Origin; once stable, they can disconnect the synchronization and let Origin independently manage the repository.

This allows Cursor to initially handle Agent, PR, review, checks, and Automation, then gradually retain more engineering state within its own system.

Therefore, Origin's product logic is clear: Git continues to handle version control, while Origin aims to rebuild the control layer above Git that revolves around high-frequency agent collaboration.

03 Old Ma is consolidating an AI production chain.

Over the past year and a half, a series of actions by xAI, X, SpaceX, and Cursor have gradually formed a more complete upstream-downstream relationship.

xAI acquires X, then integrates into the SpaceX ecosystem; Cursor gains access to Colossus computing resources and subsequently joins the SpaceX ecosystem. Meanwhile, Grok 4.6 is released, and Origin begins opening up.

This approach is similar to Musk’s past vertical integration strategy at Tesla: when external stages begin to introduce friction in iteration, continue extending upstream and downstream to bring key interfaces into the same system.

The agent is currently facing exactly this issue. While the model can perform reasoning, a software task also requires accessing repositories, modifying files, running tests, handling CI, receiving reviews, resolving conflicts, and recovering execution after failures.

If these steps are spread across multiple systems, each task cycle requires repeatedly synchronizing permissions, context, and state, causing interface costs to accumulate continuously within the running Agent loop.

Colossus, Grok, Cursor, and Origin correspond to different layers on this chain: Colossus provides computing power, Grok provides model capabilities, Cursor provides code agents and execution environments, and Origin stores repository, PR, check, and review states.

This creates a continuous workflow: the model makes a decision, Cursor converts that decision into actual changes, and Origin saves the project state and manages subsequent collaboration.

This also changes the criteria for evaluating Grok 4.6. While model capabilities remain important, the output of an Agent system also depends on the execution environment and engineering infrastructure. Even if code generation quality is high, if subsequent steps still require manual copying, execution, verification, and resubmission, the model's capabilities cannot be consistently amplified.

Once the model has reached a usable level, how quickly the code can enter the execution, verification, and merging processes will increasingly impact the overall system output.

X's position on this chain is still somewhat unclear. It possesses real-time content, user relationships, identity, and a distribution network, and may evolve in the future into a source and entry point for tasks; currently, Grok Bot is more akin to the layer of continuous task execution in product form, rather than merely the “passive chatbot waiting for questions” many imagine.

Why Cursor needs Origin can also be explained as follows: after code generation, a system is required to persistently store the project state, coordinate modifications, verify results, and connect to subsequent executions. If this location remains external, there will be a critical dependency in the Agent software production chain.

And Origin fills exactly this layer.

04 Disagreement between GitHub and Origin

GitHub already has stacked PRs, merge queues, and a REST API, and is continuously integrating Copilot coding agents into Issues, Actions, PRs, and code reviews. Looking solely at the feature list, the two sides will increasingly overlap in the future.

The differences mainly stem from the design assumptions.

GitHub is built on a mature network of human developers, so the more natural path is for Agents to integrate into the existing Issue, PR, Actions, and branch protection systems.

Cursor can redesign these components based on high-density agent collaboration. If dozens of agents run long-term in a repository, with increasing PR numbers, finer-grained changes, and faster state transitions, the review, checks, merge, and permission systems need to be reorganized around machine behavior.

The role of PR may also expand accordingly. It can evolve from a code change primarily meant for human reading into an engineering artifact unit that includes diffs, dependencies, test evidence, sources, risk levels, and approval status.

Human responsibilities will increasingly shift to the rule layer: which directories are allowed to be automatically modified, how much version jumping is permitted for dependency upgrades, what validations are required for database migrations, which approvals are needed for authentication and payment-related code, and under what conditions the Agent must stop.

Correspondingly, the metrics for Agent-native forge will also change. While 22.6 commits/s is striking, the raw number of commits alone cannot represent software productivity. More meaningful metrics would include the time from task entry to merge, local recovery capability after failures, the proportion of modifications completed automatically by policy, the computational cost of accepted changes, and the amount of human attention consumed by high-risk modifications.

Origin aims to control the software production control plane formed by the convergence of repositories, checks, reviews, permissions, and events.

Thus, the competition between GitHub and Origin will gradually focus on two paths: GitHub extending from its mature human collaboration system toward agents, while Cursor attempts to redesign the forge according to agent workloads.

05 Lao Ma is already on the next level

That said, after the release of Grok 4.6, it’s easy for outsiders to continue focusing on benchmarks—discussing coding ability, reasoning scores, and pricing. But when you look at Colossus, Grok, Cursor, and Origin together, this strategy has already extended beyond the models into the broader software production chain.

Colossus provides compute power, Grok handles reasoning, Cursor transforms model capabilities into code changes, and Origin manages the subsequent repository state, PRs, checks, and reviews. As model capabilities improve, the benefits can be directly propagated along the execution chain; even if individual model generations don't show significant improvements, the underlying infrastructure can continue to accumulate gains.

So, Grok 4.6's position on today's leaderboard may only be a temporary result. The longer-term question is who can organize the model, execution environment, and software engineering state into a continuously running production system.

While everyone is still debating which model in this round is smarter, Musk has already moved to the next level.