El 14 de agosto SpaceX cerró la adquisición de Anysphere. Sesenta mil millones de dólares, todo en acciones, Cursor convertida en subsidiaria enteramente controlada. El 17 de agosto Cursor lanzó Origin: hosting de repositorios, pull requests, browsing de código, sync bidireccional con GitHub. Tres días.
Quiero ser cuidadoso con lo que ese intervalo significa y con lo que no. No significa que SpaceX haya ordenado la existencia de un producto de code hosting durante un fin de semana. Origin viene gestándose desde diciembre de 2025, cuando Anysphere compró Graphite —la empresa de stacked pull requests fundada por Merrill Lutsky, Greg Foster y Tomas Reimers—, por lo que Axios reportó como “way over” su última valuación de $290 millones. Reimers es quien posteó el lanzamiento en Hacker News, y se identificó sin vueltas en el hilo: “I am one of the developers on Origin, and I was one of the founders of Graphite.” Origin es esa adquisición saliendo a producción ocho meses después, sobre un roadmap anterior al acuerdo con SpaceX.
Lo que sí significan los tres días es que la pregunta que dejé abierta en junio ya tiene respuesta, y llegó más rápido de lo que esperaba.
Cuando escribí sobre el acuerdo de adquisición en junio, cerré con algo deliberadamente poco vistoso: si te costaría articular qué haría falta para mover a tu equipo fuera de Cursor, vale la pena saberlo independientemente de quién sea dueño de la compañía. En ese momento era una pregunta sobre un editor. Los editores son lo más fácil de abandonar en un stack. Exportas tus settings, instalas otra cosa, tu equipo se queja dos semanas.
Origin es otra categoría de compromiso. Un forge guarda tu source of truth. Y la empresa a la que le estás pidiendo que lo guarde cambió de dueño setenta y dos horas antes de pedírtelo.
Qué es Origin realmente
Origin está en early beta en los planes Pro, Teams y Enterprise —la documentación es explícita en que “it is not available on free plans”— y llega a todos salvo a las organizaciones enterprise cuyos admins hayan optado por no participar. El titular del changelog son cinco palabras: “Cursor can now host your code.”
Tienes repositorios, pull requests con el timeline completo de commits, checks y diffs, browsing y búsqueda de código en cursor.com/codebase, clone/push/pull con git estándar, un CLI de Origin, y settings por repositorio. Puedes espejar un repositorio de GitHub dentro de Origin, y para los repositorios que nacieron en GitHub, GitHub sigue siendo el source of truth; los permisos de acceso replican los de GitHub. Los comentarios en pull requests sincronizados se propagan en ambas direcciones en segundos. Y, por supuesto, tus agentes quedan al lado de todo eso: la promesa es que el código, los PRs y los agentes por fin comparten dirección.
Lo que no tienes es casi todo lo que hace que un forge sea un forge. No hay CI propio. Las app extensions son Vercel para preview deployments, más Depot y Buildkite, y lo que estas dos hacen es correr los GitHub Actions workflows que ya tienes. No hay issue tracker. No hay self-hosting. No hay ruta de exportación documentada. La objeción más votada del hilo de Hacker News lo dijo con menos diplomacia de la que yo usaría: “Origin doesn’t even support actions. They are doing the easiest part of git hosting and no mention of anything that actually makes Github what it is.” El propio changelog de Cursor dice que las agent-native features llegan pronto, lo cual es a la vez una admisión honesta de lo que falta y una declaración de dónde creen ellos que está el diferencial.
La decisión no es si usar Origin
Acá está la distinción que nadie está haciendo, y es la que determina tu riesgo: espejar no es lo mismo que originar.
Si espejas un repositorio de GitHub dentro de Origin, GitHub sigue siendo la autoridad. Tienes una segunda copia, tus permisos siguen viniendo de GitHub, y si Origin te decepciona, dejas de espejar. El costo de equivocarte es cercano a cero. Eso es algo razonable para probar este mes.
Si creas un repositorio en Origin —cosa que ahora los agentes pueden hacer por su cuenta, según la documentación— tienes un repositorio cuyo único hogar es un producto en early beta, sin ruta de exportación documentada y sin segunda copia. No hay nada siniestro en eso; simplemente es una apuesta distinta, y es una que puedes hacer sin querer, un repo a la vez, sin que nadie la haya decidido.
Escribe la política antes de habilitarlo. Espejar, no originar, hasta que exista la historia de exportación. Esa sola frase es la mayor parte del gobierno que esto necesita.
El namespace es una puerta de una sola dirección
Este es el hallazgo que más me sorprendió, y está a la vista en la documentación.
Para habilitar Origin, tu equipo reclama un namespace: el {owner} de https://cursor.com/codebase/{owner}/{repo}. Los docs dicen dos cosas al respecto, separadas por un párrafo. Primera: “You can’t change or update your namespace after it’s claimed.” Segunda: cualquier miembro del equipo puede reclamarlo.
O sea que la identidad pública, permanente e inmodificable del code hosting de tu organización la puede fijar quien haga clic primero. Los admins pueden desactivar Origin por completo; la documentación no ofrece un rename. Para una empresa cuyas URLs de repositorio pueden terminar en documentación, en configuración de CI, en guías de onboarding y en contratos con proveedores, ese default no es menor. No cuesta nada hacerlo bien y no se puede corregir después.
Si estás en Teams o Enterprise, reclama el namespace tú mismo, hoy, como acto administrativo deliberado, incluso si no piensas usar Origin este trimestre. Ocuparlo es gratis. Perderlo por el viernes a la tarde de un desarrollador con buenas intenciones no se recupera.
Un detalle relacionado: los equipos con legacy privacy settings tienen que actualizar esa configuración antes de que Origin esté disponible. Entiende qué cambia esa actualización para el resto de tu tooling antes de hacerla para desbloquear una feature en beta.
Qué significa “Privacy Mode” cuando el producto es el almacenamiento
La documentación de Origin tiene una sección llamada Privacy, y es una sola oración: “Origin follows the Privacy Mode of the namespace owner: the team or the individual who owns the repo.”
Esa oración está cargando mucho peso, y no creo que pueda sostenerlo.
La propia página de data use de Cursor define Privacy Mode en términos de cosas que no persisten. El código en texto plano que se sube para calcular embeddings “ceases to exist after the life of the request”. Los contenidos de archivos cacheados son “temporary, never permanently stored, and never used as training data when privacy mode is enabled”. Los datos del cliente no se usan para entrenamiento, y Cursor declara que mantiene acuerdos de zero data retention con sus proveedores de modelos.
Cada una de esas garantías está construida sobre la premisa de que tu código pasa por Cursor y no se queda. La función completa de Origin es que tu código se quede. No son contradictorias —un repositorio alojado obviamente se almacena, y nadie afirma lo contrario—, pero sí implica que “Origin respeta tu Privacy Mode” no te dice nada sobre lo que de verdad necesitas saber. ¿Cuál es la política de retención de un repositorio alojado? ¿Qué pasa con él cuando cancelas? ¿Qué subprocesadores lo tocan en reposo? ¿Queda excluido de los mismos clasificadores y pipelines que Privacy Mode gobierna para el código transitorio?
No encontré esas respuestas ni en el changelog, ni en los docs de Origin, ni en la página de data use, ni en el hilo de Hacker News. No es una acusación; la documentación de una early beta está incompleta por definición. Es una razón para preguntar antes de migrar, y para conseguir la respuesta por escrito en lugar de inferirla de un producto que fue diseñado para un ciclo de vida de datos distinto.
Cómo lo pensaría yo
Resistí la narrativa de riesgo en junio y la voy a resistir ahora. La lógica estratégica de Origin es sólida y, francamente, llegaba tarde: si los agentes van a abrir pull requests, revisarlos y pushear branches, tener el código y el agente en el mismo sistema elimina fricción real. El sync bidireccional de PRs con GitHub es una rampa de entrada genuinamente bien elegida: te deja obtener el beneficio sin el compromiso. Eso es una decisión de producto madura, no una toma de terreno.
Pero un forge es lo más caro de cambiar en tu stack, y el momento correcto para pensarlo es antes de estar adentro, no después. La propiedad cambió el 14. El producto llegó el 17. Tu switching cost dejó de ser un ejercicio hipotético: es un número que puedes calcular, y este es el mes para calcularlo.
La checklist
Antes de habilitar Origin para un equipo:
- Reclama tu namespace como decisión de admin. No se puede renombrar y cualquier miembro del equipo puede tomarlo.
- Escribe una política de solo espejar y define quién tiene permitido crear repositorios que nazcan en Origin. Recuerda que los agentes también pueden crearlos.
- Pregúntale a Cursor, por escrito, qué cubre Privacy Mode para un repositorio alojado: retención, borrado al cancelar, subprocesadores en reposo.
- Revisa qué cambia actualizar los legacy privacy settings para el resto de tu despliegue de Cursor antes de hacerlo.
- Si eres Enterprise, decide el opt-out deliberadamente, antes de que el rollout te alcance y no después.
- Inventaria tu CI. Origin no tiene CI propio; Depot y Buildkite corren tus GitHub Actions existentes. Todo workflow que muevas es un workflow que tendrías que reescribir para volver.
Ninguna de estas cosas lleva una semana. Todas son más baratas ahora que en seis meses.
¿Vas a espejar algún repo en Origin este mes, o prefieres esperar a que aparezca la ruta de exportación? Me interesa especialmente cómo lo están viendo los equipos que ya tienen a Cursor aprobado por seguridad.