Contexto Técnico
No veo a Cursor IDE como un "editor inteligente", sino como una fina capa de facturación sobre las API de LLM. Por eso no me sorprende el caso en que una suscripción de $20 vuela en ~6 horas de trabajo activo: en Cursor, el costo de un agente no es una "solicitud", sino la suma de tokens de entrada/salida multiplicada por la tarifa del modelo, más los gastos generales del orquestador del agente.
Actualmente, Cursor tiene un modelo híbrido: suscripción fija y un pool de créditos valorado en dólares y vinculado a los precios de los proveedores de modelos. En Pro, por $20 al mes, recibes efectivamente unos $20 en créditos de agente. Pro+ ($60) da más créditos, Ultra ($200) aún más. Pero la clave no está en las cifras, sino en que los tokens de escenarios "caros" crecen de forma no lineal.
Lo que me llama la atención como arquitecto es la facilidad con que una sesión de agente se convierte en un contexto de millones de tokens. La razón es simple: el agente no trabaja "archivo por archivo". Lee el árbol del proyecto, captura logs, diffs, configuraciones y a menudo realiza varias iteraciones de planificación/ejecución. Si depuras Terraform o un incidente de AWS, el contexto incluye:
- múltiples módulos IaC, variables, locals, outputs;
- planes/estados, fragmentos de CloudTrail/CloudWatch, a veces políticas JSON;
- discusión de hipótesis y re-ejecuciones.
Añade el cambio a un modelo premium (o modos de gran contexto/"max") y una sola "conversación de agente" empieza a costar como decenas de solicitudes normales. Incluso intentar ahorrar con el selector automático de modelo o Composer no garantiza economía: el selector puede elegir un modelo caro si considera la tarea compleja, y Composer suele ampliar el contexto para "tener el plan en mente".
Una zona de riesgo aparte son los agentes en segundo plano y herramientas como Bugbot, que pueden facturarse por separado y más cerca del "consumo puro de API". Arquitectónicamente, esto significa que tu IDE se convierte en un consumidor constante de tokens en lugar de un asistente interactivo.
Impacto en Negocio y Automatización
En el negocio, no me interesa "qué tan bien escribe código", sino cuánto cuesta una unidad de resultado: un ticket cerrado, un incidente corregido, un módulo Terraform listo, una revisión de seguridad aprobada. En el esquema híbrido de Cursor, el precio de esa unidad puede variar drásticamente. Esto rompe la economía habitual de desarrollo: puedes planificar la carga en horas-hombre, pero no puedes planificar tokens sin disciplina y herramientas de control.
¿Quién gana con el modelo de Cursor? Los equipos donde el agente se usa con moderación: sesiones cortas, contexto limitado, reglas claras sobre qué tareas se dan al agente y cuáles al autocompletado normal. Pierden quienes ven al agente como "ponlo en piloto automático y que arregle la infraestructura". En IaC y la nube, el piloto automático a menudo se convierte en "lee todo, prueba todo, explica todo", es decir, una factura masiva de tokens.
Veo aquí un paralelo directo con cómo las empresas fallan en la implementación de IA: compran la herramienta pero no el proceso. En mi práctica en Nahornyi AI Lab, el efecto sostenible no viene de elegir "Cursor vs Windsurf", sino de la arquitectura de uso:
- Políticas de contexto: qué tiene derecho a leer/indexar el agente y qué está prohibido (especialmente en monorepos y con secretos).
- Límites y "Kill Switches": presupuestos diarios/semanales, alertas, prohibición de modelos caros por defecto.
- Clasificación de tareas: generar plantillas y cambios menores es una cosa, depurar un incidente en producción es otra, migrar infraestructura es una tercera.
- Observabilidad: métricas de tokens/costo por repositorios, equipos, tipos de tareas para detener fugas "invisibles".
En este contexto, el enfoque de Windsurf con un precio fijo por prompt de usuario parece psicológicamente más cómodo: la sorpresa financiera es menos probable. Pero no idealizo el precio fijo: a menudo implica límites ocultos en la calidad del modelo, profundidad del agente o frecuencia. Para un líder de desarrollo, la pregunta es única: ¿dónde quieres pagar? ¿"Explícitamente por tokens" o "implícitamente por limitaciones"?
Si tu objetivo es la automatización con IA en desarrollo y DevOps, necesitas un contorno operativo predecible: quién lanza los agentes, cómo se mide el costo, qué escenarios están permitidos. De lo contrario, surge una paradoja: el AI-IDE ahorra tiempo al ingeniero, pero aumenta gastos operativos impredecibles difíciles de explicar al CFO.
Visión Estratégica y Profundización
Mi pronóstico es simple: el mercado de AI-IDE se irá a dos extremos. El primero son herramientas "orientadas al cómputo" como Cursor, donde pagas cerca del costo del LLM y obtienes máxima potencia, pero debes gestionar el consumo como recursos en la nube. El segundo son productos de "experiencia fija", donde te venden previsibilidad, pero con un techo en la capacidad del agente y el contexto.
Desde la perspectiva de la arquitectura de IA, yo ya trataría los modos de agente como un pequeño servicio interno y no como una función del editor. En los proyectos de Nahornyi AI Lab, aplico a estas herramientas las mismas prácticas que para la nube:
- sandboxes para tareas riesgosas (incidentes, políticas IAM, Terraform apply);
- división de roles: "lector" vs "ejecutor", para que el agente no se convierta en un operador incontrolado;
- contexto corto obligatorio por defecto y expansión de contexto solo bajo solicitud;
- post-análisis: qué sesiones fueron caras y por qué (usualmente archivos extra, iteraciones infinitas o mala definición de la tarea).
La trampa más desagradable es la ilusión de que cambiar el modelo a "Auto" resolverá automáticamente la economía. Auto a veces ayuda, pero no arregla la causa raíz del gasto excesivo: contexto mal limitado y falta de presupuesto por tarea. Cuando el agente "mastica" archivos de logs, planes de Terraform y docenas de módulos, el ahorro en el modelo da porcentajes, no órdenes de magnitud.
Prefiero un enfoque honesto: para tareas de infraestructura complejas, o se asigna un presupuesto separado (justificado por el costo de inactividad/error), o reestructuramos el proceso para que el agente trabaje en fragmentos y entregue artefactos verificables. El hype termina donde comienza el control de costos y la responsabilidad. La utilidad existe donde el resultado es repetible, medible y encaja en los reglamentos.
Si quieres lograr una automatización con IA sin sorpresas en las facturas, te invito a discutir tu escenario: repositorios, tipos de tareas, presupuesto, requisitos de seguridad. Escríbeme — Vadym Nahornyi — y en Nahornyi AI Lab diseñaremos la implementación de inteligencia artificial en el desarrollo para que el agente acelere el trabajo en lugar de quemar los límites.