OpenAI pone fin a la asociación con Cursor tras la adquisición por parte de SpaceX: ¿Qué cambia para los desarrolladores?
OpenAI pondrá fin a su asociación directa de modelos con Cursor tras la adquisición del editor de código de IA por parte de SpaceX. El 28 de agosto de 2026, OpenAI anunció que dejaría que expirara el contrato para proporcionar sus modelos a Cursor. La fecha de desactivación prevista es el <strong>12 de noviembre de 2026</strong>.
Es importante hacer una distinción: la frase que se busca con frecuencia, *openai drops spacex cursor partnership*, suena a una ruptura completa. De hecho, la decisión afecta inicialmente al contrato a través del cual Cursor integra directamente los modelos de OpenAI en sus propias funciones. Los desarrolladores pueden seguir utilizando los modelos de OpenAI a través de su propio acceso a la API, la extensión Codex IDE o gateways compatibles.
A fecha de 5 de septiembre de 2026, el 12 de noviembre es una fecha límite <strong>propuesta</strong> y aún no confirmada como fin contractual definitivo. Por lo tanto, ahora es el momento adecuado para que los equipos revisen los flujos de trabajo críticos de Cursor en cuanto a dependencias de modelos de OpenAI.
Fuente: Simple Icons / SpaceX
En resumen
- OpenAI planea retirarse: El contrato directo para el suministro de modelos de OpenAI en Cursor se dará por finalizado.
- El 12 de noviembre de 2026 aún no es definitivo: OpenAI califica la fecha como propuesta y anunciará la fecha final tras la coordinación con Cursor.
- Cursor no desaparece: El editor y sus modelos restantes, así como las funciones propias de Cursor, seguirán existiendo en principio.
- OpenAI sigue siendo técnicamente utilizable: Se puede utilizar una clave API de OpenAI propia o un gateway compatible para funciones locales de chat y agentes.
- Codex es una ruta separada: La extensión Codex IDE se ejecuta dentro de Cursor independientemente del selector de modelos de Cursor.
- No todas las funciones de Cursor admiten BYOK: La autocompletación de pestañas, el enrutamiento automático, los agentes en la nube y en segundo plano, las automatizaciones, la CLI, así como la API/SDK, no pueden utilizar una clave OpenAI propia.
¿Qué ha pasado entre OpenAI, Cursor y SpaceX?
La situación actual es el resultado de varios pasos en pocos meses. Cursor ya había establecido una relación técnica con SpaceX antes de la adquisición. En abril de 2026, la empresa anunció una asociación de entrenamiento de modelos con SpaceXAI, declarando que utilizaría la infraestructura Colossus para ello. En agosto, Cursor confirmó posteriormente haber sido adquirido oficialmente por SpaceX.
| Fecha | Evento | Significado |
|---|---|---|
| 21. April 2026 | Cursor anuncia una asociación de entrenamiento de modelos con SpaceXAI. | Cursor obtiene acceso a infraestructura informática adicional para entrenar sus propios modelos. |
| 14. August 2026 | Cursor confirma la adquisición completada por SpaceX. | El cambio de propietario activa una situación contractual de cambio de control para OpenAI. |
| 28. August 2026 | OpenAI anuncia que dejará expirar el contrato de suministro de modelos para Cursor. | OpenAI no suministrará nuevos modelos a Cursor a través de este contrato en el futuro. |
| 12. November 2026 | Fecha de desactivación propuesta por OpenAI. | Hasta entonces, los modelos utilizados hoy a través del contrato seguirán estando disponibles durante el período de transición, siempre que Cursor no finalice el acceso antes. |
¿Por qué OpenAI retira la asociación directa?
OpenAI justifica la decisión explícitamente por el cambio de propietario. La empresa escribe que su contrato individual con Cursor contiene una ventana de tiempo limitada para la rescisión tras un cambio de control. OpenAI también explica que, basándose en sus experiencias con las empresas de Elon Musk, no puede estar lo suficientemente seguro de que su tecnología se utilice dentro de los términos de uso acordados.
Esta justificación es <strong>la posición de OpenAI</strong>. No debe interpretarse como una violación contractual probada de forma independiente por SpaceX en esta relación concreta con Cursor. Para los desarrolladores, lo más relevante es la consecuencia operativa: OpenAI afirma que desea que la rescisión sea efectiva lo más tarde posible, pero al mismo tiempo <strong>no suministrará más modelos futuros a través del contrato de Cursor</strong>.
Fuente: simpleicons.org
OpenAI no finaliza fundamentalmente todo el uso de sus modelos en Cursor. La afectación es el suministro directo y contractual de modelos a Cursor; los accesos a API propios y Codex siguen siendo vías separadas.
¿Qué significa la adquisición de SpaceX para Cursor?
Cursor en sí mismo presenta la adquisición como una aceleración de su estrategia de modelos. La empresa ya había declarado en abril que quería ampliar sus actividades de entrenamiento con la ayuda de la infraestructura de SpaceXAI. Con el cambio de propietario, Cursor se adentra así más en un ecosistema que controla sus propios modelos y su propia infraestructura informática.
Sin embargo, esto no significa que Cursor utilice exclusivamente modelos de SpaceX a partir de ahora. La documentación de Cursor sigue listando modelos e integraciones de varios proveedores. Sin embargo, los modelos que se ofrezcan a largo plazo y cómo se enruten en funciones como Agente, Auto o Agentes en la nube pueden cambiar. Por lo tanto, para los equipos, la pregunta más importante es <strong>a qué proveedor de modelos está vinculada cada función</strong>, en lugar de solo si aparece un nombre de modelo específico en el menú de selección.
Fuente: simpleicons.org
Cursor pertenece a SpaceX desde agosto de 2026. El editor se mantiene, pero su suministro de modelos, tras la anunciada retirada de OpenAI, dependerá cada vez más de proveedores alternativos y modelos propios.
¿Qué cambia concretamente para los desarrolladores?
El punto más importante es: <strong>El uso de OpenAI en Cursor no será automáticamente imposible.</strong> Sin embargo, cambiarán la vía de acceso, la facturación y, en algunas funciones, el alcance técnico. OpenAI menciona tres alternativas para los desarrolladores que deseen seguir utilizando sus modelos dentro de Cursor.
| Opción | Dónde funciona | Facturación | Restricción más importante |
|---|---|---|---|
| Integración directa de Cursor | Durante el período de transición en las funciones de Cursor previamente admitidas | A través de Cursor o la vía de integración existente | No se continuará como asociación de OpenAI después del fin del contrato; no se prevén modelos futuros de OpenAI. |
| Clave API de OpenAI propia | Chat y Agente local de Cursor | Por separado a través de la cuenta API de OpenAI | No para Tab, Auto, Agentes en la nube/segundo plano, Automatizaciones, CLI o API/SDK de Cursor. |
| Extensión Codex IDE | Como extensión separada directamente en Cursor | Suscripción adecuada a ChatGPT o cuenta API de OpenAI | No cambia el modelo detrás de Cursor Chat, Agent, Tab, Auto o Cloud Agents. |
| Gateway de IA compatible | Consultas locales de chat y agentes admitidas | A través del proveedor respectivo | La compatibilidad y las funciones del modelo dependen del gateway; las funciones en la nube propias de Cursor quedan excluidas. |
| Otros modelos en Cursor | Según la función de Cursor y la oferta de modelos actual | Según la tarifa de Cursor o la configuración del proveedor | La calidad de la salida, el uso de herramientas, el comportamiento del contexto y los costes pueden diferir de los flujos de trabajo anteriores de OpenAI. |
Opción 1: Usar una clave API de OpenAI propia en Cursor
Para muchos desarrolladores individuales, BYOK, es decir, *Bring Your Own Key*, es el sustituto más directo. Según OpenAI y Cursor, la clave se introduce en <strong>Configuración de Cursor > Modelos</strong>. Posteriormente, se pueden seleccionar modelos de OpenAI compatibles para sesiones locales de chat y agentes.
Esto da lugar a dos malentendidos comunes. En primer lugar, una suscripción a ChatGPT no incluye automáticamente el uso de la API. Las solicitudes de API se facturan por separado a través de la cuenta API de OpenAI. En segundo lugar, una clave propia no sustituye a toda la infraestructura de Cursor: Cursor Tab y Autocomplete, Auto-routing, Agentes en la nube y en segundo plano, Automatizaciones, Cursor CLI, así como Cursor API y SDK siguen utilizando modelos que Cursor proporciona o enruta por sí mismo.
Privacidad de datos con BYOK: No asuma simplemente las mismas reglas
Cursor señala explícitamente que su regla de retención de datos cero no se aplica automáticamente al usar claves API propias. El procesamiento de datos se rige entonces por el proveedor elegido. Cursor también explica que la clave API se dirige a través de los servidores de Cursor para la creación final del prompt, se transmite cifrada y no se almacena permanentemente.
Para las empresas, este es un punto arquitectónico importante: un cambio del suministro de modelos integrado a BYOK no solo cambia la factura, sino potencialmente también las suposiciones sobre privacidad de datos, registro y cumplimiento. Los administradores empresariales también pueden bloquear las claves API personales en la configuración del equipo.
Opción 2: Usar Codex directamente como extensión IDE en Cursor
OpenAI menciona explícitamente la extensión Codex IDE como segunda vía. Se ejecuta dentro de Cursor, pero está técnicamente separada del selector de modelos propio de Cursor. Los desarrolladores inician sesión con una suscripción adecuada a ChatGPT o una cuenta API de OpenAI y luego trabajan a través de su propio panel de Codex.
Esto es especialmente interesante para equipos que desean utilizar OpenAI para la codificación agentiva sin vincular todo su flujo de trabajo de Cursor a la integración directa de OpenAI. Sin embargo, la extensión no sustituye a Cursor Chat, Agent, Tab o Auto. Por lo tanto, aquellos que utilicen estas funciones deben probarlas por separado. También puedes encontrar una explicación más detallada de Codex en nuestra Guía Zerlo sobre OpenAI Codex.
Opción 3: Conectar OpenAI a través de Azure, Amazon Bedrock o una puerta de enlace
Para las empresas con gestión centralizada de la nube y los costos, una puerta de enlace puede ser más sensata que las claves API individuales. OpenAI menciona, entre otros, Amazon Bedrock, Azure y puertas de enlace compatibles con OpenAI. Cursor se puede conectar según el proveedor a través de su propia configuración o una URL base compatible.
Fuente: simpleicons.org
Amazon Bedrock es mencionado por OpenAI como una posible vía de puerta de enlace. Para los equipos, esto puede aprovechar las estructuras IAM, de facturación y de gobernanza existentes, siempre que el modelo de OpenAI deseado esté disponible y sea compatible con Cursor.
La ventaja reside en la gobernanza centralizada: las credenciales de acceso, los presupuestos y las aprobaciones de modelos se pueden controlar a través de procesos en la nube ya existentes. La desventaja es la complejidad adicional de integración. Una puerta de enlace debe admitir el formato API que espera Cursor, y no todas las configuraciones específicas del modelo se transmiten necesariamente.
Fuente: simpleicons.org
Azure también puede servir como vía de acceso administrada. Lo crucial es que el modelo deseado se implemente en la propia configuración de Azure y que Cursor admita la configuración del proveedor correspondiente.
Al igual que con la clave API propia, con las puertas de enlace también se aplica: las credenciales de acceso solo funcionan en las rutas de chat y agente locales admitidas por Cursor. Quienes utilizan Cloud Agents, Automations, Tab o Auto no pueden cambiar fácilmente estas funciones al mismo acceso de puerta de enlace.
¿Deberían los desarrolladores cambiarse ahora de Cursor?
Para la mayoría de los usuarios, no hay una razón objetiva para abandonar Cursor inmediatamente solo por el anuncio de OpenAI. El editor sigue funcionando y existen varias vías de modelos alternativas. Un cambio solo tendrá sentido si un equipo depende en gran medida de una combinación de <strong>un modelo OpenAI específico y una función propietaria de Cursor</strong> que no se pueda reproducir después de la finalización del contrato con BYOK, Codex o una puerta de enlace.
Precisamente por eso, la decisión debe basarse en una prueba de flujo de trabajo y no en el nombre del proveedor. Un agente de codificación puede seleccionar archivos diferentes en el mismo repositorio con otro modelo, llamar a herramientas de forma diferente, generar cambios más largos o más cortos e interpretar pruebas de manera diferente. Tales desviaciones son más importantes para los equipos productivos que un benchmark general.
Qué deben probar los equipos antes del 12 de noviembre
- Inventariar dependencias de OpenAI: Anota qué funciones de Cursor y qué modelos concretos se utilizan en los flujos de trabajo diarios.
- Probar BYOK por separado: Prueba escenarios de chat y agente locales con tu propia clave API y registra los costos reales de API.
- Probar Codex como vía independiente: Compara tareas como refactorización, pruebas, corrección de errores y cambios en todo el repositorio.
- Identificar funciones específicas de Cursor: Marca todo lo que requiera Tab, Auto, Cloud Agents, Background Agents, Automations, CLI o API/SDK.
- Comparar modelos alternativos: Utiliza un conjunto fijo de tareas representativas en lugar de prompts individuales subjetivos.
- Revisar la protección de datos y el cumplimiento de nuevo: BYOK y las puertas de enlace pueden tener reglas de procesamiento de datos diferentes a las del suministro integrado anterior.
- Controlar las políticas empresariales: Verifica si las claves API personales están permitidas en la organización.
- Documentar el fallback: Define qué vía de modelo o proveedor se utilizará si Cursor finaliza el acceso a OpenAI antes de la fecha propuesta.
La lección más importante: pensar por separado el editor de código IA y el proveedor del modelo
El conflicto pone de manifiesto un riesgo estructural de los entornos de desarrollo de IA modernos. Un editor puede permanecer estable mientras que los contratos de modelos, el enrutamiento, los precios o la disponibilidad cambian por debajo. Para los equipos de desarrollo, por lo tanto, vale la pena tratar tres niveles por separado: <strong>Editor</strong>, <strong>Acceso al modelo</strong> y <strong>tiempo de ejecución del agente</strong>.
Quienes mantengan los prompts, las pruebas, las reglas del repositorio y los criterios de aceptación neutrales al modelo podrán adaptarse más fácilmente a un cambio de proveedor. Especialmente en el caso de bases de código críticas para la seguridad o para el negocio, no se debe probar un modelo alternativo el mismo día de una interrupción. La fase de transición anunciada hasta noviembre ofrece una ventana de tiempo concreta para ello.
Preguntas frecuentes
¿Elimina OpenAI sus modelos por completo de Cursor?
OpenAI quiere rescindir el contrato por el cual sus modelos se proporcionan directamente a Cursor. Esto no significa que OpenAI no sea técnicamente utilizable dentro de la aplicación Cursor. Para las funciones de chat y agente locales, OpenAI menciona como alternativas una clave API propia, la extensión Codex IDE y puertas de enlace compatibles.
¿Es el 12 de noviembre de 2026 la fecha de desactivación definitiva?
No. OpenAI se refiere al 12 de noviembre como la fecha propuesta y afirma que la rescisión definitiva del contrato aún debe ser confirmada entre las empresas. Cursor también podría finalizar el acceso antes.
¿Puedo utilizar mi suscripción a ChatGPT como acceso a la API de Cursor?
No como una clave API normal de OpenAI. Las suscripciones a ChatGPT no incluyen el uso automático de la API. Para BYOK necesitas una cuenta API de OpenAI con facturación propia. La extensión Codex IDE, en cambio, puede admitir el inicio de sesión a través de ChatGPT, dependiendo de la tarifa autorizada.
¿Funciona Cursor Tab con una clave API propia de OpenAI?
No. Según OpenAI y Cursor, BYOK solo se aplica a las solicitudes de chat y agente locales admitidas. Tab y Autocomplete, así como Auto, Cloud- y Background-Agents, Automations, Cursor CLI y Cursor API/SDK, siguen utilizando modelos proporcionados o enrutados por Cursor.
¿Es Cursor realmente propiedad de SpaceX?
Sí. Cursor declaró oficialmente en agosto de 2026 que la adquisición por parte de SpaceX se había completado. En abril, Cursor ya había anunciado una asociación con SpaceXAI para el entrenamiento de modelos y la infraestructura de computación.
¿Cambia BYOK las condiciones de protección de datos?
Sí, esto puede ser relevante. Cursor explica que su regla de retención de cero datos no se aplica a las claves API propias y que el procesamiento de datos se rige por el proveedor elegido. Por lo tanto, los equipos deben revisar nuevamente las suposiciones sobre protección de datos, contratos y registro antes de una migración.
¿Deben las empresas migrar a sus desarrolladores a BYOK?
No. BYOK es solo una opción. Las empresas también pueden utilizar Codex por separado, configurar un acceso a puerta de enlace administrado o cambiar a otros modelos disponibles en Cursor. Los equipos empresariales pueden incluso bloquear centralmente las claves API personales.
Conclusión
OpenAI se retira de la <strong>asociación directa de modelos con Cursor</strong> tras la adquisición por parte de SpaceX, pero no por completo del ecosistema de Cursor. El 12 de noviembre de 2026 propuesto es una marca de transición, no un corte inmediato. Para los desarrolladores, los modelos de OpenAI siguen siendo generalmente accesibles a través de API Key, Codex y puertas de enlace compatibles.
La tarea real para los equipos no es, por lo tanto, cambiar de editor precipitadamente, sino probar sus dependencias. Quienes sepan hoy qué flujos de trabajo están vinculados a la infraestructura propia de Cursor y cuáles se pueden implementar a través de un acceso a modelo independiente, podrán reaccionar al final definitivo del contrato sin tener que reconstruir sus procesos de desarrollo a corto plazo.