Lo que realmente publicaron las dos empresas
El aviso de OpenAI
La publicación de OpenAI consta de cuatro párrafos. La frase operativa es la citada anteriormente. El razonamiento se expone claramente: "Tomamos esta decisión porque no podemos confiar en que SpaceX utilizará nuestra tecnología dentro de nuestros términos de servicio, basándonos en nuestra experiencia con las empresas de Elon Musk que violan contratos". El mecanismo es contractual: "Nuestro acuerdo personalizado con Cursor nos otorga un plazo limitado para cancelarlo tras un cambio de control".
Dos detalles de esa publicación importan más a un desarrollador que el propio razonamiento.
El primero es que el aviso es deliberadamente largo. "Para maximizar el tiempo que los desarrolladores pueden mantener el acceso a nuestros modelos a través de Cursor, estamos dando el aviso máximo previsto en nuestro contrato". Tienes hasta mediados de noviembre por diseño, no por accidente.
El segundo es fácil de pasar por alto y entra en vigor de inmediato: OpenAI escribe que decidió "mantener la cancelación del contrato hasta la fecha más tardía posible sin proporcionar futuros modelos a Cursor". El apagado es en noviembre. La congelación de cualquier novedad es ahora.
OpenAI también nombra a quién afecta esto: "Sabemos que las personas más afectadas por esta decisión son los desarrolladores que confían en los modelos de OpenAI en Cursor".
La versión de Cursor
Cursor publicó su propia nota el 14 de agosto: "Cursor ha sido adquirido oficialmente por SpaceX". Su documentación actual incluye páginas de modelos dedicadas para GPT-5.6 Sol, Terra y Luna junto con Claude Sonnet 5, Opus 5 y Fable 5, Gemini 3.1 Pro y 3.7 Flash, Grok 4.6 y 4.5, y Cursor Composer 2.5. En otras palabras, hasta esta semana, aún no se ha eliminado nada.
Lo que ninguna de las dos publicaciones dice
Cursor documenta una opción para traer tu propia clave (bring-your-own-key) — "Puedes agregar tus propias claves de API para que Cursor use tus modelos de IA preferidos" — con dos límites indicados en la misma página. Para OpenAI, cubre "Modelos de chat estándar sin razonamiento" y "Las claves de API personalizadas solo funcionan con modelos de chat. La función de autocompletado de pestañas (Tab completion) sigue utilizando los modelos integrados de Cursor". Ninguna de las publicaciones de las empresas aborda qué sucederá con esa opción una vez que finalice el contrato, y no vamos a especular. Si dependes de ello, la respuesta honesta hoy es que está documentado, es más limitado que los modelos integrados y su futuro no está definido.
Qué cambia y qué no cambia en tu configuración
Aquí está la frase que decide la mayor parte de esto, y es de Cursor, de su propia documentación de reglas:
> "Los modelos de lenguaje grande no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt."
Continúa: "Cuando se aplican, los contenidos de las reglas se incluyen al inicio del contexto del modelo."
Lee eso como una declaración de arquitectura, porque eso es lo que es. Nada de lo que le enseñaste a Cursor vive en el modelo. Vive en archivos y configuraciones que Cursor ensambla en un prompt. Cambia el modelo que recibe ese prompt y el ensamblaje no variará.
Por lo tanto, las cosas que sobreviven a un cambio de modelo, por completo y sin esfuerzo adicional:
- Reglas del proyecto (Project Rules) en
.cursor/rulescomo archivos.mdc, con su frontmatteralwaysApply,globsydescriptiony los cuatro comportamientos de activación basados en esos tres campos. AGENTS.md, incluyendo archivos anidados en subdirectorios, que Cursor combina con los directorios padres de modo que "las instrucciones más específicas tengan prioridad".- Reglas de equipo (Team Rules), creadas en el panel de Cursor, con la prioridad documentada "Team Rules → Project Rules → User Rules" y la nota de que "Todas las reglas aplicables se fusionan; las fuentes anteriores tienen prioridad cuando hay conflicto de directrices".
- Reglas de usuario (User Rules), reglas remotas importadas de GitHub en
.cursor/rules/imported/<repoName>, y habilidades (skills) en los cuatro directorios de habilidades documentados.
Y las cosas que están vinculadas a Cursor en lugar de al modelo, que es una lista diferente:
- Reglas de equipo como mecanismo de aplicación obligatoria. Una regla marcada como "Enforce this rule" es "obligatoria para todos los miembros del equipo y no se puede desactivar en Customize". Esa propiedad es una característica del panel de Cursor. No hay ningún archivo que la contenga.
- El frontmatter de
.mdccomo lenguaje de alcance (scoping). Los cuatro tipos se mapean de manera desigual con los conceptos de otras herramientas, y la conversión requiere un trabajo real. - El historial de chat y los planes guardados, que son artefactos locales de una sola aplicación.
- Cualquier cosa que una persona de tu equipo haya aprendido y nunca haya escrito, que es el elemento más grande de la lista y el que nadie inventaría.
Lo que la gente asumirá de esto, y no debería
"Tengo que dejar Cursor". No por esto. La lista de modelos documentada de Cursor todavía incluye Anthropic, Google, xAI y sus propios modelos de Composer. Si tu razón para usar Cursor era el editor, el agente o la capa de reglas de equipo, nada de eso se ve afectado por qué proveedor responde al prompt. Las personas que identifica la publicación de OpenAI son específicamente "los desarrolladores que confían en los modelos de OpenAI", un grupo real y un subconjunto.
"Mis reglas se comportarán igual en un modelo diferente". Se entregarán de la misma manera. Esa no es la misma afirmación. Las reglas son prosa, y la prosa se interpreta de manera diferente en distintos modelos; una regla que un modelo anterior seguía de forma laxa y que uno nuevo sigue al pie de la letra cambiará tu resultado. Nada de eso es un defecto en tu configuración, pero significa que la semana posterior a un cambio de modelo es una semana para leer los diffs con más atención, no con menos.
"Traer mi propia clave hace que esto no sea un problema". Lee los propios límites de Cursor mencionados anteriormente antes de confiar en eso. También en esa página: "La política de retención de datos cero (Zero Data Retention) de Cursor no se aplica cuando utilizas tus propias claves de API" y "todas las solicitudes se enrutan a través de los servidores de Cursor para la construcción final del prompt". Estos son compromisos (trade-offs), no impedimentos, pero son compromisos sobre los cuales tu equipo de seguridad ya podría tener una opinión.
"Codex lo importará todo". El importador de Codex es realmente bueno y enumera a Cursor como fuente. También es específico sobre lo que traslada: archivos de instrucciones, settings.json, habilidades (skills), complementos (plugins), carpetas de proyectos, chats de los últimos 30 días, configuración de MCP, hooks, comandos de barra diagonal (slash commands) y subagentes. Ten en cuenta lo que se describe en la fila de memoria de esa tabla: "Project memories from Claude Code". Una fuente, nombrada. Nada en el importador afirma trasladar lo que tu equipo decidió y por qué.
La solución: Mantén la mitad independiente del modelo totalmente fuera del editor
La lección aquí no es "elige un proveedor diferente". Es que un período de aviso de dos meses y medio llegó desde una dirección que nadie estaba vigilando, y las partes de tu configuración que eran portables lo eran porque eran archivos, mientras que las partes que duelen son las que vivían dentro de un solo producto.
Las reglas ya siguen ese principio: son archivos en tu repositorio, y por eso un cambio de modelo no cuesta nada. La capa de conocimiento generalmente no lo hace. Las decisiones, las correcciones, las razones detrás de los estándares: esas se encuentran en los historiales de chat, en la cabeza de las personas y en cualquier herramienta que estuviera abierta en ese momento.
MemoryLake es una capa de memoria que se sitúa fuera de cualquier herramienta individual, por lo que esa mitad se puede leer desde lo que sea que estés usando este trimestre y lo que sea que uses el próximo. La configuración consta de tres pasos.
Paso 1: Crea una clave de API
Inicia sesión y crea una clave de API. Una sola credencial para cada herramienta que conectes.

Paso 2: Sube tus primeras memorias
Entradas cortas, una afirmación cada una. Tu material de origen es el razonamiento que actualmente está implícito en tus reglas:

Decisiones con sus razones. Tu archivo .mdc dice que las migraciones son solo aditivas. El porqué no está en ningún lado. Escribe el porqué aquí, y la regla dejará de ser revertida cada vez que alguien nuevo la lea.
Correcciones que perduraron. El enfoque que el equipo intentó y rechazó, y qué salió mal. Esta es la categoría para la cual ningún formato de reglas tiene un campo.
Contexto de trabajo que no es código. Quién es el propietario de qué servicio, qué está congelado este trimestre, qué fecha límite se movió.
Enlaces externos. El panel de control, el manual de procedimientos (runbook), el rastreador de problemas (issue tracker); las cosas que un agente no puede encontrar leyendo tu repositorio.
Paso 3: Conecta tu IA y agentes
Conecta lo que usas. Se puede acceder a MemoryLake a través de MCP y de una API, y Cursor admite servidores MCP, por lo que la misma memoria está disponible en Cursor hoy. Codex, Claude Code, Cline y OpenClaw se conectan de la misma manera, y cualquier otra herramienta lee la misma memoria a través de la API. Ese es el punto: la conexión cambia, la memoria no.

Tres límites honestos. Esto no mueve tus archivos .mdc ni tus Team Rules (reglas de equipo); esos pertenecen a Cursor, y una capa de memoria no los convierte. No extiende un contrato ni restaura un modelo; nada en este artículo cambia lo que estará disponible en Cursor en noviembre. Y la memoria es contexto, no aplicación obligatoria; cualquier cosa que deba cumplirse siempre pertenece a una verificación que falle la compilación (build), un punto que la propia documentación de Cursor destaca sobre sus reglas obligatorias: "La guía de IA no debería ser tu único control de seguridad".
Qué cambia esto en la práctica
Un cambio de modelo deja de ser un acontecimiento. Las reglas se ensamblan en el momento del prompt a partir de archivos de tu propiedad. Quienquiera que responda, el ensamblaje es el mismo.
La mitad costosa se vuelve visible. Descubres qué estaba únicamente en un historial de chat mientras aún conservas dicho historial.
Los estándares de equipo conservan sus razones. La regla se mueve como un archivo; la razón se mueve como una memoria; ambos sobreviven a la siguiente herramienta.
Las fechas límite como la del 12 de noviembre se convierten en elementos del calendario, no en migraciones. Cambiar un modelo en la configuración requiere unos pocos clics. Cambiar de editor es un proyecto. Saber cuál necesitas realmente es toda la decisión.
Buenas prácticas cuando un modelo cambia bajo tus pies
Separa "qué modelo" de "qué herramienta" antes de decidir nada. Son costos diferentes y esta noticia solo obliga a uno de ellos.
Prueba la alternativa en trabajo real, no en un repositorio de juguete. Una regla que sobrevivió a la lectura laxa de un modelo puede necesitar ajustes para la lectura literal de otro.
Audita tus Team Rules obligatorias ahora. Son el elemento que no tiene representación en archivos, y su ausencia es silenciosa en cualquier otra herramienta.
Lee la tabla del importador antes de confiar en él. Codex nombra lo que traslada. Cualquier cosa que no esté nombrada es tarea tuya.
Mantén el razonamiento fuera de los archivos de reglas. Las reglas se insertan al inicio del contexto del modelo y compiten por el espacio; la forma general se encuentra en lo que los agentes de programación realmente leen.
No dejes que una fecha límite elija tu arquitectura. Dos meses y medio es tiempo suficiente para moverte de manera deliberada. También es tiempo suficiente para realizar tres cambios de herramienta que no necesitabas.
Escribe lo que el equipo aprendió esta semana. Las transiciones de modelos sacan a la luz convenciones que nadie había documentado. Esa es una oportunidad única y se cierra.
Conclusión
La publicación de OpenAI ofrece una fecha y la razón de la misma: una desactivación propuesta para el 12 de noviembre de 2026, el aviso máximo que permite su contrato, y ningún modelo futuro para Cursor mientras tanto. El propio registro de Cursor confirma la adquisición que activó la cláusula y aún documenta una lista de modelos con opciones de Anthropic, Google, xAI y Composer.
Para la mayoría de los usuarios de Cursor, esto es un cambio de configuración. La documentación de Cursor es explícita al señalar que los modelos no retienen memoria entre completados y que las reglas son lo que hace que el contexto persista, lo que significa que tus .cursor/rules, tus archivos AGENTS.md anidados y tus Team Rules son indiferentes a quién responda al prompt. Si necesitas específicamente modelos de OpenAI, tienes que tomar una decisión real, y el inventario honesto es corto: el lenguaje de alcance de .mdc y las Team Rules obligatorias no se trasladan, el historial de chat y los planes guardados no se trasladan, y el importador del otro lado nombra exactamente lo que traerá.
Lo que se traslada de forma gratuita es lo que hayas guardado como archivos, y lo que se pierde es lo que hayas mantenido como conversación. Esa es la verdadera lección de una fecha de desactivación que llega de un contrato que nadie fuera de las dos empresas había leído, y es por eso que por qué el contexto largo no es memoria sigue siendo el mismo argumento con un disfraz diferente.