Origin's source of truth depends on how you create the repository

Cursor's Origin launch contains two architectures. Treating them as one produces the wrong migration plan.

In an Origin-hosted repository, Origin is authoritative and pushes do not go through GitHub. In a synced GitHub repository, GitHub remains authoritative: pushes go there and Origin mirrors them. Pull-request comments and reviews synchronise in both directions. Those distinctions are explicit in Cursor's August 17 launch notes.

So the useful question is which mode a particular repository uses. A team can adopt an interface without changing its authoritative host. Another team can move the authoritative host. Both might say they have moved to Origin, while accepting different dependencies.

My rule for this migration: draw the successful write before comparing the feature lists.

A mirror does not remove its upstream

As an illustration, I would put two hypothetical repositories into a design review. The first is a new internal tool hosted natively on Origin. The second is a customer-facing service mirrored from GitHub, with its existing pull-request workflow still in use.

For each, I would trace a developer's push from the editor to the authoritative repository and then to the systems that consume it. That sketch must identify which service acknowledges the write, which copy a reviewer sees, and which revision the deployment process accepts.

An outage exercise then becomes specific. If the authoritative host is unavailable, can work continue locally? Can reviewers read a previously synchronised copy? Which actions must wait? A readable mirror and a writable authority solve different parts of the interruption.

These are questions to test against the product and the team's setup. The launch notes alone do not establish every failure mode, synchronisation delay or conflict-resolution behaviour. I would not turn a diagram into an uptime guarantee.

The same discipline applies during recovery. A displayed commit is useful only if the team knows whether it is current and whether the downstream system recognises it as authoritative. The handoff deserves an explicit acceptance check.

Keep future metadata out of today's decision

The announcement also says agent-native features are coming. That is a direction of travel, not evidence that a complete human-versus-agent provenance system has already shipped. Buying a repository service for promised metadata requires a separate evaluation when that metadata is available.

I would evaluate the present migration on current capabilities: repository authority, review continuity, export, access controls and the integrations actually required by the project. Future agent context can be a reason to run a pilot without becoming an undocumented production dependency.

There is a practical way to keep the discussion honest. Choose one disposable repository and write down the result expected from a push, review comment, upstream interruption and reconnect. Record which system owns each piece of state. Then run those checks in the intended mode.

If the proposed benefit is a better workflow around an existing GitHub repository, mirroring may be entirely appropriate. If the requirement is independence from GitHub's write path, evaluate native hosting and all the surrounding dependencies. Neither conclusion needs a claim that one product has killed another.

The migration decision belongs at repository level. A company-wide product announcement cannot tell you which service your next deployment still needs.

Before moving to Origin, name the system that must accept the write.