Cuando abrí mi perfil público de Cursor y vi aproximadamente 1.100 millones de tokens, la cifra me impresionó incluso a mí. Uso mucho Cursor, a veces varias horas seguidas, pero mil millones en un mes me hicieron pensar: ¿es un volumen normal para trabajar intensamente con IA o simplemente arrastro sin sentido un contexto gigantesco por el modelo?
Para entenderlo exporté el CSV de uso y examiné la estructura del consumo. Ahí había mucho más interés que en una cifra grande en el perfil. Mil millones de tokens por sí solos dicen muy poco sobre la eficiencia: importa saber qué tokens eran, qué modelos los usaron, cuánto era contexto nuevo y cuánto simplemente volvía a leer Cursor de la caché.
Qué hay dentro de mil millones de tokens
En mi exportación había 725 eventos de uso individuales y un total de 1.064.143.356 tokens. De ellos, aproximadamente 989,8 millones, el 93 %, eran Cache Read. El Input normal era de unos 63,1 millones, Cache Write, 4,6 millones, y el Output directo del modelo era de tan solo 6,6 millones de tokens.
La proporción es bastante inusual. A simple vista hay más de mil millones de tokens, pero solo cerca del 6 % es input nuevo, y el texto y el código generados directamente por los modelos representan menos del 1 % del total. La mayor parte es contexto que Cursor ya había visto y volvía a entregar al modelo mediante la caché.
Aquí se entiende de dónde sale esa cifra. Suelo usar sesiones largas de Agent en las que el modelo trabaja varias horas sobre un proyecto: estudia archivos, cambia código, ejecuta la aplicación, corrige errores y vuelve a partes ya conocidas. El contexto viaja constantemente con la sesión, aunque gran parte ya esté en caché.
Qué modelos consumieron más
El principal consumidor fue Grok 4.6 High: unos 595,7 millones de tokens, más de la mitad de todo mi consumo. Le sigue Composer 2.5, con 264,7 millones, después Claude Fable 5 Thinking: unos 151 millones. El resto de modelos representa una parte relativamente pequeña.
También hubo días concretos de carga muy alta. 14 de agosto: 185,3 millones de tokens; 13 de agosto: 184,8 millones; 18 de agosto: 144,6 millones. Solo entre el 13 y el 14 de agosto pasaron por Cursor unos 370 millones de tokens.
Sin embargo, en el CSV solo había 17 días activos, de modo que el consumo medio en los días en que realmente trabajé en Cursor fue de unos 62,6 millones de tokens. A este nivel cuesta ver Cursor solo como un editor de código con autocompletado inteligente. En mi caso se convierte cada vez más en un entorno de trabajo donde varios modelos de IA realizan de hecho una parte importante del trabajo de ingeniería.
Mil millones de tokens y 20 dólares extra
La parte más inesperada del análisis fue el coste. En Cursor Dashboard aparecen para el mismo periodo unos 948,9 millones de Total Tokens, de los cuales 946,2 millones figuran como Included y solo 2,7 millones como On-demand.
En el CSV solo encontré cinco eventos On-demand de pago que sumaban aproximadamente 20,43 dólares de gasto adicional. Es decir, sí usé Cursor muy intensamente, pero casi todo ese enorme volumen quedó dentro del uso incluido o gratuito.
Después, la pregunta «¿cómo reducir el número de tokens?» me interesó mucho menos. Si el sistema permite procesar cientos de millones de tokens sin un aumento proporcional del gasto, no tiene sentido optimizar el contador en sí. Lo mucho más importante es: si el contexto largo empieza con el tiempo a empeorar la calidad del trabajo de Agent.
Cuándo es útil una sesión larga
Mi sesión más larga de Agent duró unas nueve horas, pero la cifra en sí ya no me asusta. Si Agent trabaja todo ese tiempo en una sola tarea grande, el contexto acumulado más bien le ayuda. Conoce la arquitectura, recuerda decisiones anteriores, ya ha visto los errores y entiende por qué se descartaron ciertas soluciones.
Por ejemplo, si rehago por completo la página de inicio, tiene sentido completar el ciclo en un chat: estudiar la implementación existente, proponer una estructura nueva, escribir componentes, adaptar a móvil, ejecutar el proyecto, revisar la página en el navegador, detectar problemas y terminar los ajustes. Abrir un chat nuevo tras cada pequeño cambio solo estorbaría.
El problema no empieza cuando la sesión se alarga, sino cuando la tarea cambia y el contexto antiguo sigue viajando con ella. Si después de la página de inicio paso a los anuncios, luego al SEO, después a Cloudflare y de pronto conecto Telegram en la misma conversación, Agent recibe muchísima información que formalmente pertenece al proyecto, pero ya casi no tiene relación con la tarea actual.
Un chat, una tarea completa
De ahí mi conclusión principal: ni un prompt por chat ni un proyecto por chat. Un bloque de trabajo completo por chat.
La página de inicio puede tener su propia sesión de Agent; la sección de agentes inmobiliarios, otra; los anuncios, otra más. Migrar infraestructura, el SEO, integrar Telegram o un problema grande de API también tienen su conversación. Dentro de cada sesión es perfectamente normal hacer decenas de iteraciones y permanecer varias horas.
La frontera no está entre mensajes ni siquiera entre archivos, sino entre tareas con sentido propio. Si Agent hizo una tarjeta de inmueble y hay que retocar el diseño móvil, el hover o un margen, sigue siendo la misma tarea. Si después decido cambiar por completo la arquitectura de filtrado del catálogo, conviene pensar en una sesión nueva.
Me fijé un indicador sencillo. Si la siguiente petición empieza más o menos con «y ahora hagamos también…», conviene comprobar si realmente continúa la tarea actual o ya inicia la siguiente.
Un chat nuevo no debe significar perder la memoria
Surge una pregunta natural: si abrimos sesiones nuevas con frecuencia, ¿cómo evitamos explicar cada vez a Cursor la organización del proyecto, las reglas de diseño y las restricciones técnicas?
La respuesta es que el conocimiento permanente no debería guardarse exclusivamente en el historial del chat. Para eso existen Project Rules, User Rules y AGENTS.md. Ahí tiene sentido guardar la arquitectura, el stack, las convenciones de nombres, la estructura de directorios, las reglas de diseño, las restricciones, los comandos de ejecución, los requisitos responsive y todo lo que Agent debe conocer con independencia de la tarea.
Entonces un chat nuevo ya no es reiniciar el proyecto, sino solo limpiar la memoria de trabajo. Los conocimientos fundamentales permanecen, pero decenas de decisiones intermedias, errores y conversaciones antiguas dejan de ocupar el contexto actual.
Creo que esta distinción es especialmente importante al trabajar intensamente con IA: existe la memoria a largo plazo del proyecto, y existe la memoria de trabajo de una tarea concreta. No hace falta mezclarlas en una conversación interminable.
Una tarea grande conviene planificarla primero
Para pequeños cambios suelo poner Agent a trabajar directamente, pero las tareas grandes conviene empezarlas con Plan Mode. Si el cambio afecta a muchos archivos, a varias partes del sistema o exige decisiones de arquitectura, unos minutos de investigación previa pueden simplificar mucho la implementación posterior.
Por ejemplo, en vez de ordenar «rehaz el sistema de anuncios», es mejor dejar que Agent estudie la arquitectura, los datos, las rutas y las dependencias existentes y luego pedirle un plan concreto. Tras revisarlo, se puede pasar a la implementación.
Esto reduce el riesgo del escenario habitual: la IA escribe rapidísimo el primer 30–40 % de la solución, descubre una restricción de arquitectura y empieza a reescribir su trabajo. Cuanto mayor es la funcionalidad, más útil resulta separar las etapas de entender la tarea y escribir el código.
Subagents como un pequeño equipo
Para tareas realmente grandes aparece otro nivel: Subagents. El Agent principal puede conservar la tarea global y delegar investigaciones concretas en agentes especializados con su propio contexto.
Por ejemplo, el Agent principal se encarga del nuevo sistema de anuncios. Un subagent estudia la arquitectura existente; otro revisa API y datos; un tercero hace revisión de código; un cuarto busca problemas de móvil y accesibilidad. El principal no necesita guardar cada paso intermedio de esas investigaciones, sino sus conclusiones.
Así cambia un poco el modelo de trabajo. En lugar de un enorme chat de IA aparece una estructura parecida a un equipo pequeño, donde el Agent principal coordina y reúne los resultados de distintos especialistas.
El código todavía no es el resultado
Otra conclusión tiene que ver con el final de la sesión. Cada vez considero menos que la tarea esté terminada cuando Agent anuncia que ha escrito el código.
Un ciclo de trabajo normal debe continuar: implementar, ejecutar, comprobar el resultado, encontrar errores, corregirlos y volver a comprobar. Esto es especialmente importante en interfaces, donde un cambio puede parecer correcto en el código y romperse en el navegador o a cierta anchura de pantalla.
Si Agent tiene acceso al navegador, a los registros de consola y al tráfico de red, tiene sentido exigirle que use esas herramientas por su cuenta. Generar código es solo una etapa intermedia. El resultado debe ser una funcionalidad operativa y comprobada.
Cómo saber que toca cerrar el chat antiguo
No veo sentido a imponer límites artificiales como «un chat nuevo cada hora» o «reiniciar obligatoriamente tras cierta cantidad de tokens». La duración de la sesión por sí sola no dice nada sobre la calidad del contexto.
Pero las señales de deterioro suelen notarse. Agent empieza a olvidar restricciones acordadas, repite preguntas ya respondidas, toca archivos ajenos a la tarea, devuelve errores corregidos o contradice sus propias decisiones. A veces la razón es más sencilla: el trabajo actual se ha alejado demasiado de la tarea original.
En ese momento un chat nuevo no significa perder lo aprendido, si el contexto a largo plazo está bien guardado en las reglas del proyecto. Es solo una oportunidad de dar de nuevo al modelo un espacio limpio para resolver el siguiente problema.
Mi ciclo de trabajo con Cursor
Al final llegué a una secuencia bastante sencilla:
TAREA → PLAN → CONSTRUIR → VERIFICAR → COMMIT → CHAT NUEVO
Primero, una tarea claramente formulada. Si es grande, una fase de planificación aparte. Después Agent estudia el proyecto e implementa la solución, comprueba por sí mismo el resultado y corrige los problemas encontrados. Cuando un bloque completo está verificado, se puede guardar con un commit y pasar a la siguiente tarea en una sesión nueva.
Los conocimientos permanentes quedan en Rules y AGENTS.md, mientras las investigaciones grandes e independientes se pasan a Subagents cuando hace falta. Así no solo el proyecto de software tiene arquitectura, sino también el proceso de interacción con la IA.
Qué me enseñaron los primeros mil millones
Al principio, 1.064.143.356 tokens parecían demostrar que usaba Cursor de forma totalmente ineficiente. Tras analizar el consumo, la conclusión fue casi la contraria: cerca del 93 % era Cache Read, el Output real no llegaba al 1 % y el gasto adicional On-demand del periodo fue de apenas unos 20 dólares.
Por eso mi objetivo no será reducir el consumo a cualquier precio. Si un gran volumen de cálculo permite hacer en unos días un trabajo que antes requería semanas, el contador de tokens no es un problema en sí mismo.
Lo que hay que optimizar es la calidad del contexto, los límites de las tareas y la capacidad de Agent para llevar por sí mismo el trabajo hasta un resultado verificado. Y quizá aquí esté ocurriendo un cambio más importante que otra mejora del prompt engineering: dejamos poco a poco de aprender a hablar con un solo modelo y empezamos a aprender a gestionar agentes de IA como un sistema de trabajo completo.
@nevsky_alexander
En Instagram, Dubái más allá de la postal: familia, ciudad, descubrimientos y la vida entre proyectos. En Threads, ideas en voz alta sobre diseño e IA. En YouTube, vídeos que necesitan más espacio que una historia. Sígueme donde te sientas más a gusto y seguimos en contacto