Using Claude for anything beyond a quick question has always started with a routing decision to use Chat or Cowork? Anthropic has decided to eliminate that fork.
Starting Wednesday, Claude Chat and Cowork merge into a single interface where one conversation can handle everything from a simple answer to a multi-step project with connected tools and background execution. The company is also launching Claude Docs and Claude Slides in beta on paid plans, and moving Claude Design — previously a standalone workspace — into conversations.
The combined effect promises a streamlined experience with Claude picking up context, skills, and connectors as the work requires, and can keep running after you close your laptop.
The company is also launching Claude Docs and Claude Slides in beta on paid plans, and moving Claude Design, previously a standalone workspace, into conversations.
Two modes, one problem
Anthropic built Cowork as a desktop-first agent for bigger work and Design as a separate workspace for visual output. Both shipped earlier this year and gained traction.
“We built Cowork as a separate place for bigger work, and Design for visual work,” Anthropic said in its announcement. “People used both, and told us the frustrating part was deciding where a task belonged.”
Anthropic has run into this problem before. When the company promised 20x more usage on its Max plan, developers complained that it wasn’t always clear where one limit ended and another began. Cowork and Design created a similar headache by making people decide where to start the work before they could actually start it.
“We built Cowork as a separate place for bigger work, and Design for visual work,”
Context that finally travels
Cowork’s capabilities — local file access, multi-step execution, scheduled tasks and connected tools — now live inside the conversation. A workflow like that previously meant switching from chat to Cowork and carrying the context with it, and until Anthropic brought Cowork to web and mobile in July, it also required the desktop app.
Claude still asks before taking an action by default, but it can be set to keep working and check in only when something needs a closer look, while recurring tasks such as a weekly report can be scheduled to run every Monday without being started manually.
Output stays in-conversation
Claude Docs and Claude Slides launch in beta on paid plans, bringing document editing and presentation building directly into the app. Claude can turn work from an existing conversation into slides, which can then be edited, presented from Claude or downloaded as PowerPoint or PDF files.
The practical benefit is that a report and a slide deck based on it don’t have to begin as separate jobs with the same background supplied twice. Everything stays attached to the conversation that produced it.
Claude Design also now works inside conversations, in addition to remaining available on its own. For organizations that rely on MCP connectors to wire Claude into external tools and data, the merge means those connections are available wherever a conversation goes — without requiring users to start in a specific mode. Skills, connectors, and artifacts carry across what used to be product boundaries.
The practical benefit is that a report and a slide deck based on it don’t have to begin as separate jobs with the same background supplied twice.
What Anthropic hasn’t said
The announcement leaves some gaps. It doesn’t say whether users can force a request to stay in simple chat mode rather than letting Claude decide how to handle it, or how that decision affects context windows and token consumption. There’s no mention of API changes, which makes this a consumer and team product shift, not a platform one, at least for now.
It also doesn’t address what happens to workflows built around the old separation. Shopify rebuilt its mobile development stack in 12 weeks when it consolidated tools that had grown apart — the question for Claude power users is whether their existing Cowork setups, skills, and scheduled tasks survive the merge cleanly. Anthropic says existing Cowork chats, projects, artifacts, connectors, and skills will remain available.
Rollout starts with Pro
The unified interface rolls out to Pro and Max users across web, desktop, and mobile over the next few weeks. Anthropic says there’s nothing to enable. Team and Free plans follow. Enterprise customers are on a separate timeline; Anthropic is giving administrators at least 30 days’ notice before the change reaches their organizations.
Anthropic launched a new Browser Use tool that gives Claude a structured view of a web page in addition to what is visually rendered. Announced Thursday, the tool uses the page’s accessibility tree to help Claude find and interact with specific elements directly rather than having to work out where they are on the screen.
Browser Use is part of a broader Anthropic release that also brings Computer Use, the Skills API and Files API into general availability. Developers can access the browser tool through the Claude API using browser_toolset_20260801.
Browser Use is part of a broader Anthropic release that also brings Computer Use, the Skills API and Files API into general availability.
The change gives Claude a more direct way to interact with a web page. Instead of working out a button’s position from a viewport image and targeting coordinates such as x: 640, y: 320, Claude can receive a reference such as ref_3 tied to that element and use it when it wants to act.
Page references replace coordinates
Computer Use can operate across an entire desktop by looking at screenshots and sending mouse coordinates and keyboard commands. Browser Use works within the browser itself, where it can use page structure that would be difficult to recover reliably from pixels alone.
When Claude calls read_page, the developer’s executor returns a text representation of the accessibility tree, in which elements such as links, buttons, and text boxes can be tagged with references. If Claude later wants to click a button represented by ref_3, it can send that reference along with the requested operation rather than trying to calculate where the button is on the screen.
That said, if the tab navigates to a new page or the page changes enough, a reference that pointed to a button a moment ago may no longer work. The API will not catch that on its own, so the executor has to recognize when the reference no longer matches the underlying element, reject the action and have Claude read the page again before continuing.
Batching cuts model calls
Playwright, for example, can represent a page as an ARIA snapshot and locate elements by role rather than coordinates. At the same time, Microsoft’s Playwright MCP server already exposes structured accessibility snapshots with references a model can use to identify elements. The concepts line up closely with Browser Use, but the protocols do not: Playwright MCP speaks MCP, while Anthropic’s tool uses its own client-toolset protocol, so developers would still need an adapter that translates Claude’s requests into Playwright actions and returns the results in the format Claude expects.
Puppeteer offers many of the same building blocks, exposing the browser’s accessibility tree via Accessibility.snapshot() and providing APIs for controlling Chrome and Firefox. A developer could use those APIs for navigation or page reads, then maintain Anthropic’s reference mappings on top.
A developer could use those APIs for navigation or page reads, then maintain Anthropic’s reference mappings on top.
Slightly confusing, an unrelated open-source project also called Browser Use runs AI browser agents against Chromium through the Chrome DevTools Protocol. Despite the shared name, it has no connection to Anthropic’s tool and comes with its own agent loop and browser abstractions, so connecting the two would still require integration work.
Several browser actions can happen in one turn
Anthropic is also reducing the back-and-forth between Claude and the browser by allowing multiple actions to be requested in a single model turn. Now actions can arrive together as several tool_use blocks. The application executes them in order and sends the results back together, avoiding another model call between every click and keystroke. Anthropic says that can lower latency and costs, particularly as workflows scale from a handful of interactions to dozens or hundreds.
If Claude has to return to the model after every click or keystroke, a long browser task can quickly rack up model calls. Batching cuts out some of that back-and-forth by letting Claude request several actions at once, but the browser still has to carry them out in order because each one depends on what happened before it. If Claude asks to click a button, fill in a field, and submit a form, for example, the executor cannot simply move on to the next step if that first click fails, because everything that follows is now based on a page state Claude never reached.
Batching cuts out some of that back-and-forth by letting Claude request several actions at once, but the browser still has to carry them out in order because each one depends on what happened before it.
Developers host the browser
Browser Use is currently limited to the Claude API and is not available inside Claude Managed Agents. Adding it to a Messages API request exposes 27 browser operations by default. Claude can decide which of those operations it wants to use, but Anthropic does not execute them. The application has to translate each request into an action inside its own browser environment, preserve the session between turns and return enough information for Claude to understand what happened.
Loading all of those operations has a token cost. Anthropic’s pricing documentation says the default Browser Use toolset adds roughly 6,600 input tokens to a request, before counting screenshots, accessibility trees and other results sent back to Claude. Developers can turn off operations they do not need to reduce that overhead.
It also creates a different hosting split from some of the other tools Anthropic announced Thursday. Skills uploaded through the Skills API can run inside Anthropic’s code execution sandbox, while the Files API stores documents that can be reused by ID. Browser sessions, along with their downloads and uploaded files, stay in the developer’s environment.
Approval gates need rethinking
Claude can still encounter a prompt injection in web content or be redirected to an unexpected location, which is why Anthropic recommends running the browser in an isolated container or virtual machine with minimal access. JavaScript and file uploads should remain disabled unless needed, since code generated by Claude runs with the page’s privileges and can reach data or make requests available to that page.
Batching makes approval a little trickier because several actions can arrive at once, and a routine click at the beginning of a sequence could eventually lead to something that requires the user’s permission. That means the executor has to check actions as they happen and stop for approval when needed.
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.
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 Stackreported 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.
Pushing a local repo to Origin
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.
Syncing GitHub
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.
Reviewing code / ask Cursor / merging
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
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!”
“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.
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.
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.
Arduino has spent more than two decades making electronics and embedded programming accessible to students, hobbyists, engineers and product developers around the world. What began as an open-source microcontroller platform has evolved into a widely used development ecosystem, with its technology now helping to prototype products across industries ranging from automotive and industrial automation to […]
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.
Choosing from three optimization modes
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
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
“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 fromThe Informationreported 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/zcrpHbnlCepic.twitter.com/Vw2xyMy1jp
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.
Thomas Dohmke, who stepped down as GitHub’s CEO last year to become a founder again, is opening a preview of a distributed Git network on Wednesday that is designed to keep fleets of AI coding agents from overwhelming a single central server — and one that may soon compete directly with GitHub’s core service.
Entire, Dohmke’s post-GitHub startup, is launching a preview of this on Wednesday (but for now, it is behind a waitlist). With this, developers can mirror an existing GitHub repository onto Entire’s own infrastructure in one step.
“In the era of agents, centralized Git hosting has become a fundamental constraint, as the strain of billions of agents and developers hammering a central server shows up in the form of rate limits, high latency, or even outages,” says Dohmke in today’s announcement. “Today, we begin to return Git to its original promise, with a distributed, and soon fully decentralized and open-source network of interconnected nodes around the world. By doing so, we enable any developer or agent to host their code in-region, pushing, pulling, and cloning close to where they operate, fast and without bottlenecks, while still part of a global, collaborative network.”
The key here is that the code stays on GitHub, as Entire stresses, but coding agents can work with the Entire mirror and, as the company notes, “build without rate limits.”
Entire’s mirror is meant to absorb the constant flow of traffic that a fleet of agents can generate. That traffic, after all, is part of the reason GitHub is often buckling under pressure these days and startups like Entire have an opening.
Centralized Git hosting, Dohmke says in an interview with The New Stack, has become “a fundamental constraint” now that billions of agent and developer operations land on the same servers, showing up as rate limits, latency, and outages.
Given GitHub’s recent availability issues, it’s no surprise that startups are trying to get into this space. Entire is one — and it has the pedigree — but in June, Cursor also announced Origin, its own Git forge rebuilt for swarms of agents that are cloning and committing against a single repository in parallel.
Entire is starting with active regions in the United States, the European Union, and Australia, but the team says that now that is has spun up its first few regions, it will add more soon.
‘Git as a database’
To build its network, Entire rewrote the server part of git. GitHub, GitLab, and Bitbucket all wrap the server-side of the Git binary and build their infrastructure around it. Entire started from scratch.
“We see Git really as a database,” Dohmke says. The open source Git project has two halves, he explains: the client that an agent uses to talk to a repository, and the server a host runs to manage storage. Rather than build on that stock server, like most companies would do, “we made the decision of not going that route, and instead implemented our own Git backend.”
That only makes sense if Entire’s version has significantly better performance than the stock Git server, of course. Entire says its benchmarks have pushed the network to a sustained rate of 570,000 clones per hour, 586 pushes per second, and roughly 470 combined clone-and-push operations per second.
Pushing to a native Entire branch can run up to 25 times faster than pushing through to GitHub, Dohmke says.
Entire it will open-source both the git backend and the benchmark suite.
The foundation layer, now real
When Dohmke first described Entire’s plans to The New Stackin February, he described a three-layer platform that included a Git-compatible database at the bottom, a semantic reasoning layer in the middle, and an interface on top. Even then, he said that the database, unlike a centralized Git host, could be a globally distributed network of nodes.
But in February, Dohmke also said Entire wouldn’t necessarily end up competing with GitHub, and that code repositories would stay central to the pitch.
Pressed on whether that still holds now that Entire hosts its own copy of the GitHub repo, he calls the mirror complementary, in part because Entire can offer enterprises the ability to keep their code in a local region to fulfill local regulations. He also notes that GitHub has a huge ecosystem and an extended feature set.
“I think the question for the buyer really is, is it not better for me from an availability and reliability perspective, that I have both of these products, so if one of them is down — there’s always going to be single points of failure and human errors — then I have my mirror on the other side,” he says. “But we certainly will, in deals, compete for the dollar spent at a much smaller scale compared to the multi-billion-dollar business that is GitHub today.”
Credit: Entire
For now, that keeps the two complementary. Dohmke argues that GitHub remains the “source of truth,” or “cold storage,” while the working copy lives on Entire. But he also says that Entire will launch native repositories in the coming months, and those wouldn’t need GitHub underneath at all. All of this will be open-sourced as well.
Entire raised its $60 million seed round in February, when it had 15 employees. Felicis led it, with Microsoft’s venture arm among the backers. The company is now past 40 people and aiming for 60 by the end of the year.
Entire beyond Git: the semantic memory layer
Entire is building its middle layer — the semantic reasoning layer — in parallel with the Git platform.
The semantic layer now integrates with every major coding agent, including Claude Code, Codex, Cursor, Factory AI, and GitHub Copilot, and records each session, prompt, and tool call in the repository alongside the code.
Having this data is useful for agents, and it was the first core service the company launched. Now, it is also building more services on top of that history.
The company is adding Entire Blame, for example, which shows not just who last touched a line but the agent session and prompt behind it. There is also Entire Review, which fans out several agents for an intent-aware review, and the company is adding a code and semantic search feature that lets agents (and developers) search across code changes and the reasoning that produced them.
“Session logs are now the second most important artifact in software development, and they belong in the repository alongside the code,” Dohmke says.
Today it was announced SpaceX will buy Anysphere, Inc., maker of AI coding agent Cursor, for $60 billion.
The news comes a few days after SpaceX’s historic IPO listing, with the rocket and AI company stating in its SEC filing that the Cursor deal will likely close in Q3 2026.
Developers can now wonder how the AI coding agent might change under the Musk umbrella.
April partnership brings June ownership
SpaceX and Cursor have been flirting about a potential acquisition for a couple of months now.
Back in April, the pair inked a unique partnership, where Elon Musk’s company agreed to either pay $10 billion to the then-independent startup in a model-training collaboration or opt to buy the whole company later on for $60 billion.
That day has now come.
At the time, Cursor described its partnership with SpaceX as a way to accelerate its model training efforts, stating in a brief announcement blog post that Musk’s company would enable the startup to scale up intelligence via xAI’s Colossus infrastructure.
For its part, SpaceX posted on X back in April that working with Cursor would allow it “to build the world’s most useful models.”
SpaceX sets its sights on AI coding
It seems SpaceX has been eyeing Cursor’s talent for quite some time.
Even before the April partnership, back in March, Reuters reported that xAI had hired two engineers from Cursor. In fact, Peter Swimm, former principal product manager — Microsoft Copilot Studio, Microsoft, tells The New Stack he expects it’s largely engineering and AI talent that SpaceX hopes to gain from the new acquisition:
What remains genuinely scarce is elite AI engineering talent and the teams that know how to build these systems at scale.
“The more interesting lens is to view it as an acqui-hire and talent consolidation play. The AI coding assistant market is crowded, features are converging rapidly, and long-term differentiation is proving difficult. What remains genuinely scarce is elite AI engineering talent and the teams that know how to build these systems at scale.”
SpaceX may very well need that talent. As The New Stackwrote back in April, “SpaceX’s xAI has not had a coding hit since its grok-code-fast-1 model had its time in the sun.”
Though SpaceX’s recent IPO puts its valuation at an eye-watering $2+ trillion, its coding division has not been performing up to par, as Reuters reported in March when several aXI founders left the company. Cursor, meanwhile, rocketed to a $29.3 billion valuation at the end of 2025, scooping up $2.3 billion in Series D funding.
By bringing Cursor into its fold, SpaceX is likely hoping to score more engineering talent and level up its AI coding.
What does it mean for developers?
Swimm tells The New Stack he thinks Cursor users can expect better performance from the coding agent, assuming access to SpaceX’s deep resources.
What he says remains to be seen is whether the tool will “maintai[n] broad model support and ecosystem neutrality” or face sweeping changes à la Twitter when Musk morphed the social media company into X:
“For Cursor users, the question isn’t whether the product gets better. With significantly more resources behind it, it probably will. The question is whether it remains an independent platform optimized for developers or becomes another component in a larger corporate strategy.”
Whoever owns the interface where developers spend eight hours a day gains visibility into how software gets built, which models get adopted, and ultimately where AI spending flows.
If that’s the case, he also predicts procurement evaluations will change, as enterprises may now assess the coding agent as one piece of Mr. Musk’s growing AI puzzle rather than an independent vendor.
Bigger picture, Swimm says the SpaceX acquisition highlights where real strategic value likely now sits. He doesn’t see AI coding agents, themselves, as the gamechanger but the access they provide into developer workflows:
“What it [the acquisition] does suggest is that access to developer workflows is becoming strategically valuable. Whoever owns the interface where developers spend eight hours a day gains visibility into how software gets built, which models get adopted, and ultimately where AI spending flows.”
Login
