Contexto técnico
He analizado este caso de uso no como un espectador, sino como alguien que constantemente implementa AI integration en herramientas de trabajo de forma habitual. La idea es sencilla: en Cursor puedes especificar una URL personalizada para un proveedor compatible con OpenAI en Settings → Models, introducir la clave de API y activar la opción de sobrescribir la URL base. En papel, suena casi ideal.
Pero luego llega la realidad. Si quieres pasar una suscripción de GPT o un proxy de traducción de peticiones a través de Cursor, te topas con la API que utiliza realmente el cliente. Según los comentarios y el análisis de la documentación, la ruta personalizada de Cursor a menudo pasa por /chat/completions, mientras que los nuevos escenarios de GPT ya esperan en algunos puntos la Responses API.
Y aquí, no prometería milagros. Para los endpoints OpenAI-compatible habituales, esto suele funcionar rápido. Para los modelos GPT más recientes o esquemas de suscripción, se necesita un proxy bien diseñado que traduzca el formato de las peticiones, o bien aceptar que algunas funciones se comportarán de forma errática.
Entiendo perfectamente por qué la gente hace esto. No es por las pruebas de rendimiento, sino por la UX: Composer 2.5, exploración, trabajo con interfaz de usuario y ediciones rápidas de código en un solo entorno. En este modo, hacer build AI automation dentro del IDE es mucho más agradable que saltar entre la CLI y la web.
En cuanto al consumo de Composer, obtuve una señal práctica importante: en una base de código nueva consume significativamente más durante los primeros días, tras lo cual se activa una especie de almacenamiento en caché inteligente. En las discusiones, se mencionó una referencia: en dos semanas de uso promedio se consumió un 60%, y el primer 30% se agotó muy rápido. No es una prueba científica, pero sirve como referencia de campo útil.
Qué cambia esto para las empresas y la automatización
En resumen, ganan los equipos que priorizan la velocidad de pensamiento sobre la arquitectura estéril. Cursor con un buen modelo integrado realmente acelera la exploración de código, las iteraciones de UI y la rutina de ingeniería menor.
Pierden quienes esperan que un custom endpoint reemplace de forma económica y fluida la integración oficial. No lo hará si los protocolos no coinciden. Una sola capa de compatibilidad incorrecta y el agente se comportará de forma extraña, mientras que los costes aumentarán sin aportar valor.
Yo plantearía dos soluciones: diseñar desde el principio un proxy para el formato específico de las peticiones, o bien no tocar un esquema frágil allí donde el equipo necesite una UX de producción predecible. En Nahornyi AI Lab analizamos precisamente estos cuellos de botella: dónde se requiere AI implementation para acelerar al equipo y dónde es mejor construir un entorno adecuado para que la automation with AI no se convierta en un experimento costoso. Si Cursor, tus herramientas internas o tu agente de código ya están consumiendo demasiado tiempo y presupuesto, analicemos tu escenario y diseñemos una solución sin magia innecesaria.