La mañana del lunes 17 de agosto, Cursor empezó a lanzar a todos sus usuarios de pago una novedad llamada Origin: un servicio de alojamiento de código, todavía en beta temprana, con la posibilidad de que los planes empresariales opten por no participar. Unas tres horas y media después, GitHub sufrió una degradación de servicio a escala global que se prolongó 6 horas y 42 minutos, con tasas de error cercanas al 20% en algunas funciones.
Ambos hechos no tienen relación de causalidad, pero que coincidieran la misma mañana resulta más convincente que cualquier evento de lanzamiento.
Qué ofrece Origin realmente
En la interfaz aparece una nueva pestaña llamada Codebase, donde se pueden crear y gestionar repositorios; los proyectos locales se pueden clonar o subir mediante la CLI, y la dirección del repositorio tiene el formato cursor.com/codebase/<name>. Todo el conjunto de funciones de Pull Request se trasladó por completo: línea de tiempo, historial de commits, estado de checks, cambios de archivos, revisión de diffs, comentarios, merge; incluso los PR que te asignen en GitHub se pueden revisar directamente desde Cursor.
La relación con GitHub es de sincronización bidireccional. Tras conectar con una organización de GitHub, los repositorios existentes se sincronizan con Origin, los comentarios escritos en Cursor se envían a GitHub y viceversa. Según el discurso oficial, GitHub sigue siendo la fuente de verdad (source of truth), los pushes siguen yendo directamente a GitHub, y los usuarios pueden desconectarse en cualquier momento.
Entre los terceros ya integrados están Vercel, Depot y Buildkite, que cubren despliegues de vista previa y flujos de CI.
La parte de revisión no se escribió desde cero. En diciembre de 2025, Cursor adquirió Graphite, una startup especializada en revisión de código; su equipo y su tecnología son ahora los que sostienen el flujo de revisión de Origin. En su momento, la adquisición parecía una función más para el editor; en retrospectiva, se parece más a un acopio de insumos para la capa de alojamiento.
Por qué hacerlo ahora
En los últimos años, la posición de Cursor ha sido la de "una capa que se sienta encima de GitHub". Cuando un agente termina de modificar código, tiene que abrir un PR, el PR pasa por GitHub, los comentarios de revisión se leen en GitHub, y la herramienta sincroniza los resultados de vuelta al editor. Cada ida y vuelta entre sistemas en esa cadena le resta contexto disponible al agente y añade latencia.
Traer la capa de alojamiento a casa ahorra menos peticiones de red de lo que parece; lo que realmente está en juego es el poder de definir el producto. Cuando la fuerza principal que escribe código deja de ser humana y pasa a ser de agentes, la propia forma del repositorio debería cambiar con ella: quién puede ver qué archivos y en qué momento, cómo se divide un cambio, a quién se le muestra una revisión; hoy todas esas reglas están fijadas según los hábitos de colaboración humana. El eslogan oficial de Origin, "diseñado para la escala de los agentes", se refiere precisamente a esta capa.
Del lado de GitHub, la ventana de oportunidad está realmente abierta. En 2018, Microsoft compró GitHub por 7.500 millones de dólares en acciones; ocho años después, su papel en la era de la programación con IA resulta bastante incómodo: tiene que alojar el código de todo el mundo, vender su propio Copilot y, al mismo tiempo, abrir API para un montón de agentes de la competencia. La degradación de más de seis horas en agosto puso en duda la premisa implícita de que "alojar es sinónimo de infraestructura".
Las probabilidades de esta jugada
Siendo realistas, a corto plazo nadie va a sacar sus repositorios de GitHub solo por Origin. Los issues, stars, forks, configuraciones de CI y los hábitos de los colaboradores externos de los proyectos de código abierto están arraigados en GitHub; el coste de migración recae en el lado social, mientras que, técnicamente, esa es en realidad la parte más fácil de resolver. La propia Cursor lo sabe, por eso la primera versión apuesta por la sincronización y no por la sustitución.
Donde sí hay opciones reales es en los repositorios internos de las empresas. El código privado no necesita comunidad ni PR externos; a la empresa solo le importa si el agente funciona rápido, si el flujo de revisión es fluido y si puede recortar una suscripción. Los usuarios de pago de Cursor ya se concentran en esta capa, y Origin se coloca directamente en su flujo de trabajo existente, con un umbral de prueba prácticamente nulo.
Un cálculo aproximado también deja clara la cuestión. En una empresa de doscientas personas, GitHub Enterprise, cobrado por usuario, cuesta una cifra de cinco dígitos en dólares al año; la suscripción de Cursor es otro gasto aparte, y el solapamiento de funciones entre ambos crece con rapidez: revisión, disparadores de CI, exploración de código, Origin ya lo hace todo. En la temporada de renovación, las empresas solo necesitan hacerse una pregunta: ¿es necesario pagar por los dos? La respuesta depende de si la estabilidad de Origin puede sostenerse, no de quién tenga la lista de funciones más larga.
Detrás de todo esto hay también un factor de capital. Cursor ya forma parte de SpaceX, y el flujo de caja de la matriz es suficiente para sostener durante años un servicio de alojamiento que a corto plazo no da beneficios; un juego completamente distinto al de una startup que, haciendo lo mismo, todavía tiene que cuidar la percepción de sus inversores.
El indicador que de verdad hay que vigilar no aparece en las notas de la versión: dentro de medio año, cuántas empresas habrán fijado Origin como repositorio principal, y no como copia sincronizada. La sincronización es un estado de transición; el repositorio principal es la conclusión.
Fuentes: registro de cambios oficial de Cursor, SiliconANGLE, CocoLoop, Slashdot; se verificaron el alcance de la apertura de la beta, la duración de la degradación de GitHub de 6 horas y 42 minutos junto con el criterio de tasa de error, y la cronología de la adquisición de Graphite.