Cursor has officially thrown its hat into the code-hosting ring with Origin, a Git-compatible platform built for a world where AI agents generate the commits.

The beta launch announced late on Monday comes two months after Tomas Reimers took to the stage at Cursor’s developer conference in San Francisco to tease its agent-focused GitHub alternative. That happened to be on the very same day that Elon Musk’s SpaceX confirmed it had tabled a $60 billion bid to acquire Cursor outright, and with that deal formally closing on August 14, Origin becomes the first product Cursor has shipped as a fully owned SpaceX subsidiary.

Notably, however, Origin landed on the same day that GitHub itself went down worldwide, turning what might have been a routine beta rollout into a “case in point” on why Cursor was building Origin to begin with. But while the 8-hour outage may have seemed like fortuitous timing on the surface, GitHub going offline when it did wasn’t great for Cursor, given that Cursor needs a fully operational GitHub for new users to get the ball rolling. As SpaceXAI’s Matt Palmer acknowledged on X: “We were going to ship this earlier, but GitHub was down. Importing your GitHub repos as a first onboarding step is non-optimal if GitHub is down.”

Still, GitHub’s troubles predate this particular blackout. As The New Stack reported in June, the platform has logged hundreds of incidents over the previous 12 months as commit volume jumped from 1 billion a year to 1.4 billion a month, with AI agents alone generating more than 17 million pull requests monthly — growth GitHub traced to infrastructure bottlenecks like MySQL contention and webhook overload.

“Cursor has joined a slew of technology companies looking to rebuild version control for a world where agents work around the clock.”

In an interview with The New Stack at the time, GitHub COO Kyle Daigle discussed the scaling problem: “It’s not just about normal scaling,” he said. “It’s now making sure we can scale at 30 or 40 times” annual growth, as opposed to doubling each year, which GitHub had historically planned around.

Fast-forward to today, and Cursor has joined a slew of technology companies looking to rebuild version control for a world where agents work around the clock, querying and pushing to repositories faster than any human team ever could.

Origin story

Origin marks a fairly significant expansion of Cursor’s ambitions. Until now, its agents have largely operated on code hosted elsewhere; with Origin, Cursor is pushing to own more of the underlying development infrastructure itself.

At launch, that starts with the basics. Users can create and host Git repositories directly inside Cursor, with the new Codebase tab acting as the home for Origin repos.

Those repositories still behave like Git repos outside Cursor. Developers can clone them locally, add an Origin remote, and push code from the command line — essentially putting Cursor in the role normally occupied by a service such as GitHub.

Cursor isn’t demanding an all-or-nothing migration, either. Existing GitHub repositories can be synced into Origin and displayed alongside Cursor-hosted repos, while GitHub remains the source of truth for projects that started there.

Pull requests are built in too, including diffs, comments, checks and merging. Cursor’s agents sit directly alongside that code: from the browser, users can ask questions about what they’re viewing, have an agent make changes, update a PR or push a branch.

That combination is arguably the more consequential part of Origin: the repository, pull request and coding agent now all live inside the same product — giving Cursor more control over the environment in which code is stored, reviewed and changed.

Rob Whiteley, CEO of Coder, a cloud development platform built for enterprises, sees Origin as a “smart play” — most of the industry’s energy has gone into the tools that write code, he argues, while comparatively little has gone into what happens to that code after it’s produced.

“GitHub is starting to crack under the weight of agentic code development, and an agent-native source code forge is needed,” Whiteley tells The New Stack. “Everyone is integrating the ‘writing code’ stack, from editor and chat to agents, tools and LLMs. No one else is really integrating the ‘managing code’ stack, where code gets stored, versioned, reviewed and merged.”

For now, Origin’s restricted to Cursor’s Pro, Teams and Enterprise plans — nothing on the free tier, it seems — and the rollout itself is staged, so not everyone will have access to it quite yet.

How is Origin different to GitHub?

For now, there’s no escaping the fact that there isn’t a great deal that’s different from trusty ol’ GitHub, a fact that wasn’t entirely lost on the online community. And Origin’s own team isn’t shying away from that, either.

Tomas Reimers, the Origin engineer who co-founded Graphite, a code-review startup Cursor acquired in early 2026, fielded questions directly from developers on Hacker News after the launch.

“We’re intentionally releasing this as a GitHub alternative where we meet them toe-to-toe on functionality.”

Asked what set Origin apart from GitHub beyond uptime, Reimers concedes that it’s very “very little,” in all honesty. “We’re intentionally releasing this as a GitHub alternative where we meet them toe-to-toe on functionality,” he writes.

He does note that more is on the way: in the coming weeks, Reimers explains, Origin should start shipping deeper agent integrations, tooling that can make sense of agent-written code, and automation that pushes pull requests toward a mergeable state on their own.

“Expect a lot more from us,” he continues. “We wanted to release a beta so people could start experimenting with our scalability and extensibility themselves. Over the next few weeks, you can expect a handful of features starting to change source control to better understand and work with agents.”

Several in the online community also highlighted the timing of Origin’s launch. Gergely Orosz, author of The Pragmatic Engineer newsletter and an investor in Graphite, initially took to X to complain about GitHub’s ongoing performance issues, despite the number of engineers it has at its disposal.

Incredible how GitHub’s eng team knows reliability (having zero nines) is their #1 problem for ~6 months now and seemingly not being able to get a handle on it. Despite so many solid engineers working on it

My bet: arch decisions years ago bite back v hard now https://t.co/wHbCpugD6X

— Gergely Orosz (@GergelyOrosz) August 17, 2026

Within an hour, however, Orosz was back to comment on Origin. “Cursor could not have timed their launch announcement of their hosted code service better either,” he writes. “If GitHub was stable, these alternatives would not be as interesting / popular!”

“These alternatives,” as Orosz puts it, are already forming an orderly queue in GitHub’s shadow.

The ‘GitHub alternative’ surge

The most direct comparison to Origin is perhaps Entire, a distributed Git network founded by Thomas Dohmke, who stepped down as GitHub’s CEO last August. Entire, essentially, mirrors repositories across regional nodes, with GitHub remaining the source of truth for now — though that could change once teams start creating repos natively on the platform. The company raised a $60 million seed round in February, with investors including Microsoft’s venture arm, and it formally went to market in July.

“Cursor could not have timed their launch announcement of their hosted code service better either. If GitHub was stable, these alternatives would not be as interesting / popular!”

GitLab, meanwhile, is also rethinking source control for an agent-heavy world, announcing a private beta of “Next Generation Source Code Management” — internally called Project Switch — back in June. Instead of agents cloning an entire repository to read or change a handful of files, the system lets them query the server for exactly what a task needs, with each agent’s visibility capped at the minimum required.

Elsewhere, code editor startup Zed has also been teasing a new approach to version control since last year, and in early August the company finally debuted Delta, a “multiplayer environment for coding with agents and reviewing what they build,” as the company puts it.

“Delta keeps code and conversations connected, so developers and agents can work together with the full context of how the code came to be,” Zed co-founder and CEO Nathan Sobo wrote at the beta launch.

Underneath, Delta runs on DeltaDB, which keeps a live copy of conversations and in-progress work synced across a team. It sits alongside a project’s existing Git repository, and works with agent tools including Claude Code. What that changes in real terms: comments stay attached to the code they refer to as an agent keeps editing it.

Despite GitHub’s persistent reliability problems, Whiteley doesn’t see Cursor’s version becoming a major enterprise play any time soon, mostly due to the pain of switching.

“Most [enterprises] have already spent a lot of pain and money standardizing on GitHub, and moving again would mean a lot of pain for limited ROI today,” he says. “That could change as ‘vibe coding’ generates an order of magnitude more code. If Cursor commits to keeping Origin open enough for enterprises to trust and integrate with, it could become much more appealing over time.”

So while there is a clear flurry of activity in the “GitHub alternative” realm, it’s still too early to say whether any of them will cut it in the long term. GitHub has an 18-year head start: it launched in 2008, popularized the pull-request review model most of these newcomers are trying to disrupt, and was snapped up by Microsoft in 2018. It also set off the current wave of AI coding tools itself with the launch of Copilot in 2021 — the same wave now generating the volume its own infrastructure is struggling to absorb.

For now, GitHub remains the only one of these platforms actually handling this kind of developer activity at scale. However, at a lofty $2 trillion valuation, SpaceX is one of the world’s most valuable companies, which puts Cursor in a strong position when it comes to investment — not just in its own AI models, but in the infrastructure underneath them.

The post “If GitHub was stable, these alternatives would not be as interesting”: Cursor launches Origin as GitHub goes dark appeared first on The New Stack.

A developer supervising four coding agents has four changes in flight at once, each in its own git worktree. That isn’t an exotic setup anymore: Anthropic’s documentation now treats a worktree per session as the default way to run agents in parallel, and what was an expert workflow two years ago is the recommended starting point today.

The branches themselves aren’t new. Git made them cheap 20 years ago so developers could isolate changes and work on several things at once, but in practice a developer switched between branches and shipped one change at a time. That kept everything below the code layer singular: one continuous integration (CI) queue, one staging environment, one database everyone tested against. The number of changes contending for those shared resources was capped by headcount, and before agents, only larger teams ever hit the cap.

“Coding agents removed the cap. The branch can no longer stop at the code layer.”

Coding agents removed the cap. Those four branches are no longer something one developer rotates through. They are four active changes moving toward merge in parallel. The gap becomes unworkable: branching is free at the code layer and missing everywhere below it. Each change needs to exist all the way down the stack, not as a diff in a directory but as a running, testable version of the system. The branch can no longer stop at the code layer.

Parallel until the first shared resource

Code branches in milliseconds. A worktree gives each agent a private copy of the repository for the cost of a checkout, and 10 agents can work side by side without seeing each other’s edits.

The output shows up downstream. Telemetry from Faros AI across more than 10,000 developers found that teams with high AI adoption merge 98% more pull requests while review time grows 91%. Nothing downstream of code generation was sized for that arrival rate.

Then each change needs to run. There is one staging cluster, one seeded database, one message queue, one set of dependent services, and every branch that reaches this floor stops being parallel. Four agents produce four candidate changes in an afternoon, and all four line up behind the same shared environment to find out whether they work.

The queue is more expensive than it looks, because agents don’t wait well. An agent blocked on an environment either sits idle holding a stale view of the system or plows ahead validating against mocks, and the developer supervising it context-switches away. By the time the shared environment frees up, the cheap part of the work has to be partially redone.

The bottleneck isn’t code generation, and it isn’t review capacity alone. It’s the first shared resource a change touches, because a branch that can’t run is a branch that can’t be trusted.

“The bottleneck isn’t code generation, and it isn’t review capacity alone. It’s the first shared resource a change touches.”

A branch is a delta, not a copy

The way out is to stop treating branching as something git does and start treating it as something every layer does. Branch-based development names the pattern: each layer of the stack offers a cheap, instant, disposable branch primitive, so a change can exist end to end without duplicating anything it didn’t touch.

The mechanic is the one git established, and everyone has been living on for two decades: branches are cheap because they share everything unchanged and carry only the delta. The rest of the stack has been relearning that idea layer by layer ever since — share by default, isolate what changed.

Naming the pattern matters because each layer discovered it separately and called it something different. Worktrees, pipeline caching, preview deploys, database branching, and environment sandboxing sound like five unrelated features. They’re the same idea applied at five layers, and seeing that changes what you ask of the layers that lack it.

The upper layers learned this years ago

CI absorbed the lesson a decade ago. Every branch gets its own pipeline run on a shared runner pool, with build caches doing the copy-on-write work of reusing unchanged artifacts. Nobody provisions a build system per branch, and nobody queues behind a single global build anymore.

The front end followed. On Vercel, every push to a non-production branch gets its own preview deployment by default; Netlify works the same way, and the branch itself is one immutable build plus routing on shared hosting infrastructure. Reviewers stopped asking whether a change works on someone’s laptop, because the change is already running somewhere.

Both cases have the same shape: the expensive machinery is shared, the branch is thin, and creating one is cheap enough that nobody thinks about it. That’s what a layer feels like once it has a branch primitive.

Each of these primitives also changed behavior once it arrived. Per-branch CI made it normal to run the full test suite on every push instead of nightly. Preview deploys made it normal for a product manager to click through a change before merge. Cheap branches don’t just remove a queue; they raise the bar for what gets checked before merge.

The data layer was supposed to be the hard case

Databases carry state, so conventional wisdom said branching would never work there. Then Neon, PlanetScale and Xata shipped it anyway, and Neon’s documentation now makes the parallel explicit: branch your data the same way you branch your code.

A database branch is a copy-on-write view over shared storage pages, created in seconds regardless of how large the database is. Schema migrations and risky data changes get validated against production-shaped data instead of a stale seed script, and the branch disappears when the work merges.

“If the layer with the most state can hand out branches in seconds, statelessness was never the real requirement.”

The data layer matters to this story because it removed the best excuse. If the layer with the most state can hand out branches in seconds, statelessness was never the real requirement. Whatever is still unbranched is unbranched by choice.

The runtime is the last layer to learn the trick

The microservices runtime resisted longest because it looks nothing like a file tree. It has live traffic, a service graph and dozens of moving dependencies, and the naive branch, a full copy of the environment, is so expensive that most teams concluded branching did not apply here.

The copy-on-write move works anyway. Run one shared, stable version of the system that is continuously deployed from main. For each change, deploy only the services the change touches as a lightweight ephemeral environment, and route each test request through the changed services while everything else falls through to the shared stable versions. The environment branch costs roughly what the changed services cost, which is why one can exist for every change an agent produces.

Routing is the part that sounds exotic and isn’t. A request tagged with a label gets steered to the changed service versions at each hop, propagated through the call chain the same way trace context already flows through most instrumented systems. The shared stable environment plays the role of main, the changed services are the delta, and the label is the pointer that assembles a coherent view of the system per request.

This isn’t a hypothetical architecture. Uber built SLATE to give each developer an ephemeral environment routed against shared production-grade dependencies because contention over staging could not keep up with its developer count.

What an agent-native stack means

Put the layers together and a different development model appears. An agent picks up a task, and the change gets a worktree, a pipeline run, a preview, a data branch, and a running environment from the start. Validation stops being the scarce resource that serializes everything upstream of it.

Teams are already composing the lower layers. Bitso, a crypto exchange with 250-plus engineers, pairs an environment branch with a database branch for each change, so the runtime delta and the data delta travel together and shared staging stays out of the critical path.

That end-to-end branch is what the phrase agent-native software development lifecycle should mean. Not agents wired into yesterday’s pipeline, but a stack where any change, human or machine, can exist at every layer for as long as validation takes and disappear afterward.

The payoff compounds with agent count. When the branch primitive at every layer is a delta over something shared, validation concurrency scales with cluster capacity instead of with budget, and the number of changes a team can prove correct per day rises with the number it can generate. That is the ratio that decides whether agent adoption shows up as shipped software or as a longer queue.

The audit is cheap to run. Follow one change from worktree to validated and note the first layer where it waits on something shared. That’s where your stack stops branching. 

For most teams, the answer is the runtime, and if it’s yours, Signadot is a practical place to start.

The post Anthropic recommends a git worktree per agent. Your runtime infra makes that a problem. appeared first on The New Stack.

Cursor, the AI coding tool recently acquired by Elon Musk’s SpaceX in a $60 billion all-stock deal, has launched a model router designed to direct every coding request to whichever model handles it best, bypassing the need to pay frontier prices for work that doesn’t need it.

Under the hood, the new Cursor Router uses a triage system à la a hospital emergency room: It looks at what a request actually needs — how hard it is, what it’s for, the surrounding code — and picks a model that is the best fit. A quick fix goes somewhere cheap, while a genuinely hard problem gets escalated to something closer to frontier-grade.

Notably, developers and admins also have access to three distinct modes that nudge that balance in either direction, favoring speed and cost over raw power, or vice versa if needed.

The broader rationale for Cursor Router, according to the company’s own field CTO David Pan in a social media post on Wednesday, is that developers shouldn’t have to become experts in model performance just to write code.

“We briefly went insane and decided every software engineer should also become an expert in model benchmarks, thinking levels, and cache hit rate.”

“We briefly went insane and decided every software engineer should also become an expert in model benchmarks, thinking levels, and cache hit rates,” Pan writes.

We briefly went insane and decided every software engineer should also become an expert in model benchmarks, thinking levels, and cache hit rates.

Cursor Router is out today. It picks the model for each task based on measured quality against cost. Fable 5 level performance for… https://t.co/3B2103mGWr

— David Pan (@davep) July 22, 2026

Early community feedback has largely echoed Pan’s sentiment: Fatih Arslan, a software engineer at PlanetScale, notes on X that engineers already juggle the choice between cost and capability by hand — defaulting to a cheap, fast model for routine work and saving the slow, expensive one for “serious tasks.”

Nice! I wanted something like this for a long time. See my previous rant last year. I think as engineers, we're already developing skills ourselves which model to choose. We use a less costly/fast model for implementing chore details, but use a higher reasoning model (slow and… https://t.co/5y5xMOR2E6

— Fatih Arslan (@fatih) July 22, 2026

“We already spend quite a bit [of] time on [choosing models],” Arslan writes. “Why not automate that part? Cursor Router does the automation.”

“We already spend quite a bit time on it [choosing models]. Why not automate that part?”

In a separate blog post published on Wednesday, Cursor claims that early access customers saved 30-50% compared to routing everything through Opus 4.8, with no drop in output quality.

Working model: Taking control of the stack

The launch follows a run of moves by Cursor to control more of its own AI stack. In May, the company released Composer 2.5, an update to its in-house coding model built for long tasks at a lower cost than frontier options from Anthropic and OpenAI. Composer 2.5, like its predecessor, is built on Moonshot AI’s Kimi K2.5, an open-weight model out of China.

Now, with the weight of one of the world’s most valuable companies behind it (SpaceX has attained a market cap of $1.5 trillion since its June IPO), Cursor is pushing a powerful frontier model of its own.

On July 8, Cursor and SpaceXAI jointly released Grok 4.5, a mixture-of-experts model built on a new foundation dubbed V9, which Musk had previously noted was roughly 1.5 trillion parameters. The model’s trained on trillions of tokens of real Cursor usage data and available across all Cursor plans at $2 per million input tokens and $6 per million output tokens.

With Composer handling cheap, fast work, and now the Grok-branded frontier line for more serious horsepower, Cursor has its own models in the mix alongside the usual list of outside providers. And this gets to the heart of why Cursor built Router: Most developers pick one model and stick with it regardless of the task, billing simple work at frontier prices it doesn’t need.

Sending every request to its own models would be the easy way to keep that money in-house, but it would also mean shipping inferior output on some tasks — so Router instead sends each request to whichever model actually suits it, Cursor’s own or not.

The lay of the land

Model routing itself isn’t exactly new. OpenRouter has offered a version since 2023: a single API sitting in front of more than 400 models from over 60 providers, including OpenAI, Anthropic and Google. Its own auto-router feature does roughly what Cursor Router does — classify a request, then send it to whichever model fits the task and the person’s stated preference between cost and quality.

More recently, OpenRouter launched Fusion, which takes a slightly different approach: instead of picking one model, it sends a prompt to several models at once and uses a judge model to synthesize the strongest answer out of all of them.

This past month ushered another entrant to the mix: Japan’s Sakana AI released Fugu in June, which instead breaks a single task into subtasks and routes each piece to a different model, pitched by Sakana as a hedge against relying on any one AI provider.

“[Cursor Router is] a great example of how a technological innovation immediately translates into a product improvement.”

Not everyone rates some of these other attempts, though. On Wednesday, Kirill Balakhonov, head of AI products at Nethermind, argues on LinkedIn that Cursor’s version succeeds precisely because it’s focused on coding specifically, rather than trying to be a general-purpose router for any task.

“A great example of how a technological innovation immediately translates into a product improvement… rather than an abstract idea like Sakana Fugu or OpenRouter Fusion,” Balakhonov writes, predicting both of those broader routing efforts would fade from use.

What’s new, perhaps, is some of the names emerging behind an array of model diversity efforts. In early July, Microsoft launched a $2.5 billion services unit dubbed Microsoft Frontier Company, embedding thousands of engineers at customer sites to help them build with a mix of AI models.

Judson Althoff, CEO of Microsoft Commercial Business, told Reuters at the time that the push came partly from watching rivals like DeepSeek and Google’s Gemini close the gap on OpenAI. Referring to the original Copilot, he admitted, “we made a mistake by binding it to OpenAI models only.”

If the company with the deepest single-model relationship in the industry is walking it back, the idea for model flexibility has clearly gone mainstream — certainly if this week is anything to go by.

Ramp and Meta get in on the act

On Tuesday, Ramp, the $44 billion spend-management behemoth, opened up Ramp Router, an early-access public version of the model router it built to manage its own AI bills internally, which it says cut its LLM costs by roughly 30%. It’s free to start, requires no Ramp account, and routes across OpenAI, Gemini, and select open-source models including Kimi through an OpenAI-compatible endpoint.

The very same day, Jyoti Mann from The Information reported that Meta is also working on a model router. According to internal documents cited in the report, an incubator inside Meta called AAI Labs is developing a new product named Switchboard that would score each request for difficulty and send simpler ones to smaller, cheaper models — aimed initially at cutting Meta’s own AI agent costs, though it reportedly could end up as a public release.

Meta has particular reason to want this. Data from Runpod’s State of AI report, published in March, suggests Meta’s open Llama models are now a marginal presence in production: Llama 4 has near-zero real-world deployment, with Alibaba’s Qwen having overtaken it as the most-deployed self-hosted LLM.

Meta has also been building proprietary models in response. Muse Spark, its first model out of the newly formed Meta Superintelligence Labs, shipped in April. That was followed in July by Muse Spark 1.1, Meta’s first model with a public, paid API, priced at roughly a quarter of what OpenAI and Anthropic charge for comparable models.

Meta is aggressively targeting the incumbents, and Switchboard fits the same pattern: a way to make it easier for users to cut costs, switch models freely, and, where it makes sense, land requests on Meta’s own models instead.

But amidst all this hullaballoo about model routing, there is perhaps a broader question of openness. Not of the models themselves, which is a fervent debate in itself, but of whether the routing decision itself — the logic that decides which model handles which request — should sit inside a vendor’s own closed product at all.

“Is anyone building this as open-source?”

Elvis Saravia, a former technical product marketing manager at Meta AI who co-founded DAIR.AI, took to X to argue that it shouldn’t, given how differently teams weigh cost against quality.

“Is anyone building this as open-source?” Saravia asks. “It feels like this is something you don’t want to offload to an API. We all work with different trade-offs, so we need the ability to achieve custom routing.”

Recommended reading. Cursor Router routes tasks to the right model.

Is anyone building this as open-source? It feels like this is something you don't want to offload to an API. We all work with different trade-offs, so we need the ability to achieve custom routing. https://t.co/zcrpHbnlCe pic.twitter.com/Vw2xyMy1jp

— elvis (@omarsar0) July 22, 2026

As for Cursor’s own version, Router is currently available to Teams and Enterprise customers only, across desktop, web, iOS, CLI, and Cursor’s SDK. It’s not yet clear whether it will eventually land on individual plans.

The post Cursor, Ramp, and Meta are all building model routers — but two have major model ambitions themselves appeared first on The New Stack.