Cursor Built Its Own Git Host — Here's How Origin Actually Works

Two very different companies shipped Git-hosting news the same week — and neither called it competing with GitHub, but both are clearly rethinking Git infrastructure for a world where AI agents, not just humans, are the ones pushing code. Cursor published a detailed engineering breakdown of Origin, a from-scratch Git hosting platform built on a storage system called Continuity. Days earlier, Block (Jack Dorsey's company) previewed Buzz Projects, extending its self-hosted, Nostr-based Buzz workspace — which explainx.ai has covered before — to also host Git repos directly.

TL;DR

The problem: Git hosting wasn't built for how agents use Git

Cursor's post opens with the observation that Git's distributed design — every copy of a repo is identical, nothing on the server is special — makes naive hosting deceptively simple to start and genuinely hard to scale. The core obstacle is packfiles: the binary format Git uses to store and transfer data, optimized for compactness on a single machine but poorly suited to distributed access, since reading any single file requires walking a graph of pointers where each hop depends on the value of the last.

GitHub hit this wall in its early Rails-monolith days and, after failing with networked filesystems and block-level replication, landed in 2013 on Spokes: store real Git repos on fast local disks, replicate them to a small number of servers, and keep every replica in sync using three-phase commit (3PC), a consensus algorithm. That approach became the industry default — most major Git hosts run some variant of it — and it worked well for over a decade.

Cursor's argument is that Spokes has two structural limits that matter a lot more now than they did in 2013:

1. 3PC doesn't scale past a handful of replicas. Consensus latency is bound by the slowest node in the cluster, so adding replicas to handle a big monorepo's CI load actually hurts push throughput.
2. Every repo needs the same minimum replica count regardless of how little it's used. Coding agents now spin up huge numbers of small, often disposable repositories — Cursor says Spokes "still requires three replicas for every one of these repositories," wasting capacity on idle copies that can't be trimmed without risking data loss.

How Continuity actually works

Cursor's fix decouples "where does this repo physically live" from "what is actually true." The core primitive is a write-ahead log (WAL) stored in S3-compatible object storage. Every push is written as a WAL entry and only acknowledged once it's fully persisted — no server, no routing table, no consensus round required to know a push succeeded.

A local copy of the repo on fast NVMe disk still exists for actual Git operations (Cursor deliberately kept this part, since Git itself is highly optimized for local disk access) — but it's treated as a rebuildable cache, not a source of truth. If a repo is missing from a given server, it gets materialized fresh from the WAL on demand. Routing which server holds which repo uses rendezvous hashing rather than a database; if that routing is momentarily wrong (a server goes down, a deploy happens), the system just materializes the repo somewhere else rather than failing.

For replication, Cursor uses "optimistic" gossip over UDP to notify replicas a push happened, but never trusts the gossip packet itself — every replica verifies against S3 with a conditional GET before serving a read, so a lost or misdirected gossip packet can't produce a stale or incorrect answer; it just adds a small amount of latency on the next read.

Cursor reports (from internal synthetic stress tests, not independently verified figures) linear read-throughput scaling tested up to 100 replicas, sustained push throughput around 120/second on standard S3 and roughly 300/second on the lower-latency S3 Express One Zone tier, and successful use for everysphere, Cursor's own large internal monorepo.

Block's Buzz Projects: a very different starting point

Where Cursor built new infrastructure to scale a familiar hosting model, Block took the opposite approach: extend an identity and messaging system it already had. Buzz — which explainx.ai covered in detail in July — is a self-hostable, Apache 2.0 workspace built on the Nostr protocol, where humans and AI agents share channels using the same signed-event identity model. Buzz Projects, previewed as an "Experiments" feature, extends that same identity system to Git: repos live on your own relay, pushes and pulls work over plain Git Smart HTTP with no special tooling, and your Nostr key — the same one that signs your chat messages — also signs your commits, pull requests, and reviews.

The pitch is different from Origin's: not raw scale, but unified, self-owned identity and context. A pull request in Buzz Projects links back to the chat conversation that produced it; an agent's contribution history is a portable, cryptographically verifiable record tied to its own key, not a GitHub username your org controls. Block is explicit that this is early — the web UI lags behind the CLI/terminal experience, and the feature is labeled experimental.

What this means if you're choosing infrastructure today

Neither of these is a GitHub migration you can do this week. Origin is internal infrastructure underneath Cursor's own product — there's no indication in Cursor's post that it's opening Origin as a standalone hosting service others can sign up for. Buzz Projects is explicitly early and experimental, useful today mainly if you're already running Buzz for agent-human collaboration and want your Git activity in the same identity graph.

The pattern worth noticing: two companies, building for very different audiences (a coding-agent product vendor and a self-hosted communication platform), independently concluded that agent-heavy workflows strain assumptions Git hosting made when humans were the only ones pushing code — replica counts sized for human teams, identity models built around individual GitHub accounts, and audit trails that don't naturally capture which agent under whose authorization made a given change. Expect more of this, not less, as agent-authored commits become a larger share of total push volume.

When to use Origin vs GitHub (and what security changes)

Origin is not a GitHub replacement you choose — it is infrastructure Cursor runs for you. If you use Cursor's agent features and it spins ephemeral repos for experiments, those repos likely live on Origin already. You do not migrate by toggling a setting; Cursor owns the hosting layer.

Stay on GitHub (or GitLab / self-hosted) when:

• You need org-wide SSO, compliance attestations (SOC 2, FedRAMP), or third-party app integrations that assume GitHub's API surface.
• Your audit requirement is "which human approved this merge" — GitHub's mature PR review model, branch protection, and CODEOWNERS still win for regulated teams.
• You depend on Actions, Packages, or the broader GitHub ecosystem — Origin solves storage and replication, not CI marketplaces.

Watch Origin-style architectures when:

• Agents create high-cardinality, low-lifetime repos (one per task, discarded after merge) and your current host charges or replicates as if each were a production monorepo.
• You run massive monorepos where read replicas need to scale past Spokes' practical ceiling without hurting push latency.
• You are building an agent product and need hosting whose economics match agent-shaped traffic, not human-shaped traffic.

Security implications worth an audit either way:

If agents push code in your org today, the actionable step is not picking Origin over GitHub — it is treating agent credentials, ephemeral repos, and merge approval as a distinct threat model from human developer access. Branch protection written for human review cadence does not automatically catch an agent that opens, merges, and deletes a repo within minutes.

Summary

Cursor's Origin replaces the industry-standard "Spokes" Git hosting architecture (3-replica consensus via three-phase commit) with a write-ahead log in S3 as the single source of truth, letting it scale replicas independently in both directions — a handful for a throwaway agent repo, a hundred-plus for a giant monorepo under heavy CI load. Block's Buzz Projects takes a different route to a related problem, extending its self-hosted Nostr identity system to Git hosting so agent and human contributions share one signed, portable audit trail. Neither is a finished GitHub replacement yet, but both are concrete signals that Git infrastructure built for human-scale teams is being rebuilt for agent-scale usage.

Related on explainx.ai

• OpenAI pauses frontier RL over Astra cyber risk
• Anthropic "Mind Viruses" multi-agent research
• Headless SaaS for agents: charge per interaction
• Block Buzz: self-hosted Nostr workspace for humans and agents
• DFlash 2 on MLX: local inference on Apple Silicon
• Claude protein design and analytical chemistry results
• Why AI agents haven't gone mainstream — consumer adoption

Official sources: Cursor — "Git at any scale" (August 18, 2026) · Block Engineering — "Projects in Buzz" (August 18, 2026)

Architecture details reflect each company's own published account as of August 19, 2026. Cursor's performance figures come from its own internal synthetic stress tests and have not been independently benchmarked; Buzz Projects is explicitly labeled experimental by Block.