Cursor ahora quiere alojar tu código, no solo escribirlo. El 17 de agosto de 2026, la compañía comenzó a lanzar Origin, su propio servicio de alojamiento Git, en una versión beta temprana para todos los planes de pago. Repositorios, solicitudes de extracción (pull requests), navegación de código y sincronización bidireccional con GitHub se incluyeron desde el primer día, todo dentro de una nueva pestaña de Codebase en el editor.
La propuesta es directa: las forjas Git fueron diseñadas para humanos que suben commits unas pocas veces al día, y Cursor apuesta a que la próxima década del control de versiones será moldeada por agentes que abren ramas, actualizan PRs y fusionan trabajo las 24 horas del día. Origin es la primera plataforma de alojamiento diseñada desde el principio con esa suposición.
Si tu equipo desarrolla APIs, esto te afectará antes de lo que crees: tus especificaciones OpenAPI, tus pruebas de contrato impulsadas por CI y tu flujo de trabajo de revisión residen dondequiera que apunte tu remoto Git. Aquí te explicamos qué hace Origin hoy, qué le falta y cómo mantener un flujo de trabajo de API (incluida la automatización de pruebas de Apidog) intacto si lo pruebas.
Qué es Origin
Origin es una forja Git en la nube operada por Cursor. La beta inicial incluye:
- Repositorios alojados que puedes crear desde la pestaña Codebase, desde la web en
cursor.com/codebase, o desde un agente de Cursor durante una tarea. Los remotos siguen el patrónhttps://cursor.com/codebase/{owner}/{repo}, y los comandos estándargit clone,pushypullfuncionan con ellos. - Solicitudes de extracción (Pull requests) con las partes que esperarías: una línea de tiempo, commits, verificaciones, diferencias (diffs), comentarios y fusión, revisables dentro del editor o en el navegador.
- Navegación y búsqueda de código en la web, con configuraciones a nivel de repositorio y de codebase.
- Una CLI dedicada para flujos de trabajo de terminal, separada del editor.
- Integración de agentes, que es el punto clave: los agentes pueden leer la base de código, responder preguntas al respecto, hacer cambios, actualizar PRs y subir ramas desde la misma interfaz donde revisas su trabajo. Según el registro de cambios, más “funciones nativas para agentes se lanzarán pronto”.
Disponibilidad: solo planes Pro, Teams y Enterprise. Los usuarios de planes gratuitos no pueden crear repositorios de Origin, y las organizaciones empresariales pueden optar por no participar por completo. Detalles como las cuotas de almacenamiento, una API pública y los webhooks aún no están documentados, lo cual es importante recordar antes de mover algo importante. Consulta la documentación de Origin de Cursor para el estado actual.
Origin culmina un mes ajetreado para la compañía; la cobertura de prensa, incluyendo el informe de SiliconANGLE, también señala que el lanzamiento se produjo días después de que SpaceX completara su adquisición de Cursor. Para un repaso sobre el lado del editor del producto, nuestra guía de Cursor "todo lo que necesitas saber" cubre los fundamentos.
La sincronización con GitHub es la parte inteligente
Nadie migra una empresa de GitHub en un fin de semana, y Cursor lo sabe. Por eso, la beta de Origin se basa en una sincronización bidireccional en lugar de una migración:
- Refleja un repositorio de GitHub en Origin y los repositorios sincronizados se actualizan en tiempo real.
- Los comentarios y reacciones de las PR se sincronizan en ambas direcciones en cuestión de segundos: un comentario dejado en Cursor se publica en GitHub, y una respuesta de GitHub aparece en Cursor.
- GitHub sigue siendo la fuente de verdad para cualquier repositorio que se originó allí. Los pushes siguen fluyendo a GitHub; Origin es un espejo en vivo con una mejor narrativa para agentes, no un remoto de reemplazo.
- Los permisos de acceso reflejan tus configuraciones de lectura/escritura de GitHub, por lo que la sincronización no amplía silenciosamente quién puede acceder a un repositorio.
Este es el mismo patrón de adopción de bajo compromiso que funcionó para Cursor contra VS Code: no pidas a nadie que se vaya, siéntate junto al incumbente y deja que el nuevo flujo de trabajo gane por conveniencia. Puedes probar la interfaz de usuario de revisión de PR de Origin el lunes sin decírselo a tu equipo de plataforma, porque nada de tu configuración de GitHub cambia.
El subtexto estratégico es más difícil de ignorar. GitHub ha sido el hogar predeterminado del código durante quince años, y su propia historia de IA se desarrolla a través de Copilot, que compite directamente con Cursor; comparamos los dos en Cursor vs GitHub Copilot. Que Cursor construya su propia forja es una declaración de que ya no quiere que su hoja de ruta de agentes esté limitada por la plataforma de un competidor.
Qué falta (y es mucho, por ahora)
La beta es una forja, no una plataforma DevOps completa. Desde su lanzamiento, Origin tiene:
- No hay CI/CD nativo. En su lugar, Depot y Buildkite se conectan a través de la pestaña de Aplicaciones de un repositorio y pueden ejecutar tus archivos de flujo de trabajo de GitHub Actions existentes en los repositorios de Origin. Es un puente pragmático, pero es una dependencia de terceros donde GitHub tiene un producto incorporado.
- Sin incidencias, sin discusiones, sin wiki. La revisión de código es el único primitivo de colaboración.
- Sin autoalojamiento, sin API pública documentada, sin webhooks, sin límites de almacenamiento declarados.
- Un socio de lanzamiento notable: conecta Vercel desde la pestaña de Aplicaciones y cada PR obtiene un despliegue de vista previa que se envía a producción al fusionarse, el mismo flujo que Vercel ejecuta para los repositorios de GitHub. (Vercel ha estado lanzando rápido últimamente; es el mismo Gateway que actualmente ejecuta el descuento de GPT-5.6 Sol.)
Ninguna de estas brechas importa mucho mientras GitHub siga siendo la fuente de verdad detrás de la sincronización. Importan enormemente el día en que un equipo considere hacer de Origin el primario. Trata la beta como una capa de revisión y agentes, no como infraestructura.
Qué significa esto específicamente para los equipos de API
Tu flujo de trabajo de API probablemente toca la forja en tres lugares: la especificación reside en el repositorio, las pruebas de contrato se ejecutan en CI en cada PR, y los revisores aprueban los cambios en ambos. Así es como cada uno se mapea a Origin hoy.
Especificaciones y revisión de diseño. Si sigues un flujo de trabajo de diseño primero, tu archivo OpenAPI es el artefacto más revisado en el repositorio. Los diffs de PR de Origin manejan YAML como cualquier otro texto, y la sincronización bidireccional de comentarios significa que un revisor de API que trabaja en GitHub y un operador de agente que trabaja en Cursor ven el mismo hilo. Nada se rompe, nada mejora todavía; la parte interesante llega cuando los agentes comienzan a proponer cambios de especificación como PRs, que es exactamente el bucle para el que Origin está construido. Nuestra guía para ejecutar Apidog CLI dentro de Cursor ya cubre permitir que el agente del editor valide una especificación antes de que se haga el commit.
Pruebas de contrato CI. Apidog CLI se ejecuta como un paso en cualquier sistema de CI, y la respuesta de Origin a CI es “trae tus flujos de trabajo de GitHub Actions a través de Depot o Buildkite”. En la práctica, eso significa que un paso de flujo de trabajo existente como apidog run --scenario smoke-tests debería transferirse sin modificaciones, porque el formato del archivo de flujo de trabajo es el mismo. La advertencia honesta: no hemos verificado la capa de compatibilidad de Depot con Actions contra cada acción en la práctica, y nadie más lo ha hecho esta semana. Ejecuta tu pipeline contra un repositorio desechable espejado antes de confiarle una rama de lanzamiento.
Los cambios impulsados por agentes necesitan puertas a prueba de agentes. Toda la premisa de Origin es que llegue más código de los agentes, más rápido. Esto eleva el valor de las verificaciones automatizadas y deterministas en cada PR, porque los revisores humanos se convierten en el cuello de botella. Un conjunto de pruebas de contrato que falla la compilación cuando un esquema de respuesta se desvía es precisamente el tipo de puerta que escala con el rendimiento del agente, y se configura en cinco minutos en Apidog: define aserciones contra tu especificación una vez, ejecútalas desde la CLI en cualquier CI que ejecute tus PRs de Origin. Descarga Apidog si quieres tener esa puerta en su lugar antes de que tus agentes obtengan acceso de push, y consulta nuestra guía de pruebas de QA con Cursor para el ciclo de pruebas más amplio.
¿Deberías probarlo?
Un atajo para la decisión:
- Desarrolladores individuales y pequeños equipos en planes de pago de Cursor: sí, bajo riesgo. Refleja un repositorio, usa la vista de PR, mantén GitHub como la verdad. No pierdes nada si Origin no se afianza.
- Equipos con una gran inversión en GitHub Actions: pruébalo primero en un proyecto secundario. Tus flujos de trabajo teóricamente se portan a través de Depot o Buildkite, pero “teóricamente se portan” no es un plan de migración.
- Cualquier persona cuya historia de cumplimiento nombre a GitHub: espera. Sin autoalojamiento, sin API documentada y una etiqueta de beta temprana hacen que Origin sea inviable para código regulado hoy en día.
- Equipos que ya usan los agentes de Cursor intensivamente: para esto es Origin. Si usas las funciones de agente de Cursor a diario, que los agentes abran y actualicen PRs en una forja que los trata como usuarios de primera clase es una verdadera mejora en el flujo de trabajo ahora mismo.
La forja se está convirtiendo en una superficie para agentes
La verdadera historia no es que GitHub tenga un nuevo competidor. Es que Cursor cree que el repositorio mismo está a punto de convertirse principalmente en una interfaz para agentes, con humanos revisando en lugar de ser los autores de la mayoría de los cambios. Gane o no Origin, toda forja será arrastrada en esa dirección, y los equipos de API lo sentirán primero, porque las especificaciones y las pruebas de contrato son las puertas de revisión más automatizables en el software.
La preparación es la misma en cualquier caso: haz que tus verificaciones de API sean programables e independientes de la forja. Apidog mantiene tus especificaciones, mocks y escenarios de prueba en un solo lugar y los ejecuta desde una CLI a la que no le importa si el PR vino de un humano en GitHub o de un agente en Origin. Pruébalo gratis, y tus puertas de revisión se moverán contigo sin importar quién gane la guerra de las forjas.
Preguntas frecuentes
¿Es Cursor Origin gratuito? No. El almacenamiento de código de Origin requiere un plan de pago de Cursor (Pro, Teams o Enterprise). Los usuarios de planes gratuitos no pueden crear repositorios de Origin, y las organizaciones empresariales pueden optar por no usar Origin por completo.
¿Tengo que dejar GitHub para usarlo? No. El diseño de lanzamiento asume que no lo harás: refleja un repositorio de GitHub en Origin y GitHub seguirá siendo la fuente de verdad, con los pushes, comentarios de PR y reacciones sincronizándose en ambas direcciones en tiempo casi real.
¿Origin tiene CI/CD? No de forma nativa. Depot y Buildkite se conectan a través de la pestaña de Aplicaciones y ejecutan tus archivos de flujo de trabajo de GitHub Actions existentes. Vercel también está integrado para despliegues de vista previa de PR.
¿Pueden los agentes usar Origin directamente? Sí, esa es la característica principal: los agentes de Cursor pueden crear repositorios, responder preguntas sobre la base de código, actualizar solicitudes de extracción y subir ramas. Cursor dice que se avecinan más funciones nativas para agentes; nuestra guía del modo agente de Cursor cubre lo que los agentes ya pueden hacer en el editor.
¿Cómo ejecuto pruebas de API en las solicitudes de extracción de Origin? De la misma manera que lo haces en GitHub: ejecuta Apidog CLI como un paso de CI. En Origin, eso significa conectar Depot o Buildkite al repositorio y reutilizar tu flujo de trabajo de Actions existente, con tus comandos `apidog run` sin cambios.