Cómo quemar menos tokens en Cursor y Claude sin empeorar el trabajo

Esta nota es contexto; el trabajo actual son los paquetes Web & eCommerce y la entrada US → EMEA.

Hay un patrón que vemos repetirse en equipos que adoptaron herramientas de IA con entusiasmo en 2025 y que en 2026 miran la factura con cara de póker: la factura no creció porque los modelos se encarecieran. Creció porque nadie miró qué se les estaba enviando.

La aritmética incómoda es esta. El precio por millón de tokens de un modelo es un número fijo y publicado. Lo que no es fijo es cuántos tokens generan tus hábitos de trabajo — y para la mayoría de operadores que usan Cursor y Claude a diario, el gasto dominante no es la salida brillante del modelo. Es el mismo contexto, pagado una y otra vez: los archivos del repositorio readjuntados en cada mensaje, el system prompt reenviado en cada llamada, el bucle de agente que relee medio proyecto en cada reintento.

El contexto es la factura. Una vez interiorizas eso, recortar tokens deja de ser buscar un modelo más barato y pasa a ser enviar menos, enviarlo una sola vez y frenar los bucles antes de que se pierdan. Nada de esto empeora el trabajo. Casi todo lo mejora, porque la misma disciplina que ahorra tokens — contexto acotado, briefs claros, cambios planificados — es la que hace que la salida del modelo sea más precisa desde el principio.

Esta es una guía práctica de campo, no un ensayo de tarifas. Para la versión estratégica de la pregunta del coste — qué clases de modelo deberían cargar con qué trabajo — lee nuestro cálculo de coste open vs frontier. Este artículo va de los hábitos que hay debajo.

Qué quema tokens de verdad

Antes de las tácticas, un inventario honesto. Cinco cosas dominan el gasto en el desarrollo asistido del día a día, más o menos por orden:

Fuente de gasto	Por qué quema	El arreglo en una línea
Contexto de conversación reenviado	Cada mensaje de un chat largo reenvía el historial acumulado	Chat nuevo por tarea; hilos cortos
Adjuntos de contexto sobredimensionados	Adjuntar carpetas o repos enteros cuando lo relevante eran tres archivos	Acota las menciones @ a lo que toca la tarea
Bucles de agente sin acotar	Cada reintento relee archivos, relanza búsquedas, se reexplica	Planifica primero; dale al agente un brief, no un deseo
System prompts y reglas repetidos	Las mismas instrucciones reenviadas, sin caché, en cada llamada	Prefijos de prompt estables + prompt caching
Modos de razonamiento siempre activos	El razonamiento extendido multiplica los tokens de salida en tareas que no lo necesitan	Ajusta el esfuerzo de razonamiento a la dificultad

Fíjate en lo que no está en la lista: la tarifa del modelo. Un equipo con contexto disciplinado sobre un modelo premium gasta con frecuencia menos que un equipo con contexto descuidado sobre uno barato — porque el descuidado envía diez veces más tokens por unidad de trabajo útil, y luego los vuelve a enviar cuando el primer intento falla.

Cursor: acotar, planificar y saber cuándo no usar el agente

Cursor es donde se produce la mayor parte del gasto en equipos de desarrollo, porque es donde vive el contexto.

Adjunta lo que toca la tarea, nada más

La guía del propio Cursor es más estrecha que los hábitos de la mayoría: usa menciones @ cuando sabes qué archivos son relevantes, y omítelas cuando no — el agente encuentra los archivos con su propia búsqueda, que suele salir más barata que un volcado especulativo de carpetas (documentación de Cursor). Adjuntar @src/ porque la respuesta está “por ahí dentro” paga cada archivo de la carpeta en cada mensaje posterior.

La regla de trabajo: menciona los dos o tres archivos que toca el cambio. Si de verdad no sabes dónde vive el cambio, dilo en el prompt y deja buscar al agente — una búsqueda dirigida cuesta una fracción del volcado preventivo.

Chats cortos y tareas pequeñas

Cada chat comparte una ventana de contexto fija y, a medida que el hilo crece, Cursor comprime las partes antiguas en un resumen para hacer sitio. Mucho antes de llegar ahí, ya estás pagando por reenviar un historial cada vez más rancio con cada mensaje. El hábito que lo arregla es, además, buena ingeniería: una tarea, un chat. Termina el cambio, verifícalo, empieza de cero. Los diffs pequeños son más baratos de producir, más baratos de revisar y muchísimo más baratos de reintentar cuando algo falla.

Planifica antes de soltar el bucle

El objeto más caro del desarrollo asistido es el run de agente sin acotar: “arregla los tests que fallan” contra una base de código que el modelo no ha mapeado, reintentado tres veces, cada intento releyendo archivos y relanzando búsquedas. El coste en tokens es malo; el coste de revisar un diff extenso y medio correcto es peor.

La alternativa cuesta un mensaje: pide primero un plan. Que el modelo diga qué cree que está roto, qué archivos va a tocar y qué pinta tiene el cambio — y apruébalo o corrígelo antes de que corra nada. Un plan son unos cientos de tokens de salida. Un bucle a la deriva son decenas de miles, más tu tarde.

Escribe el stack una sola vez, en reglas

Si te descubres tecleando “usamos Astro, CSS propio, nada de Tailwind, los strings viven en los archivos de i18n” por tercera vez esta semana, esa frase pertenece a un archivo de reglas del proyecto, no a tus prompts. Las reglas de Cursor adjuntan las convenciones del proyecto automáticamente — dejas de pagar atención (y tokens) por reexplicar tu propio stack, y el modelo deja de cometer la clase de error que nace de no conocerlo.

Saber cuándo el modo Agente es la herramienta equivocada

El modo Agente se gana su coste cuando el modelo necesita de verdad buscar, leer varios archivos, hacer ediciones coordinadas y verificar. Para un renombrado, un cambio en una función o un ajuste de copy, la edición inline o un chat corto y acotado hacen el mismo trabajo en una pasada por una fracción de los tokens. Tirar del agente por defecto es como coger la furgoneta para echar una carta — funciona, y has pagado la furgoneta.

Claude: cachear lo estable, acortar el system prompt, disciplinar las herramientas

Para equipos que llaman a la API de Claude directamente — herramientas internas, agentes, pipelines — las palancas son estructurales.

El prompt caching es la mayor palanca de la API

Si tus llamadas comparten un prefijo estable — system prompt, definiciones de herramientas, documentos de referencia —, el prompt caching cambia la economía de raíz. En la API de Claude, las lecturas de caché se facturan a 0,1× el precio base de entrada; las escrituras, a 1,25× (documentación de prompt caching de Anthropic). Para un pipeline que envía el mismo preámbulo de 5.000 tokens unos cientos de veces al día, es la diferencia entre pagar precio completo cientos de veces y pagarlo, a efectos prácticos, una.

La disciplina que exige es arquitectónica: mantén estable la parte estable. Pon las instrucciones fijas, las definiciones de herramientas y el material de referencia al principio del prompt, en un orden consistente, y deja al final todo lo que varía por petición. Una frase reescrita a la ligera al principio del system prompt invalida toda la caché que viene detrás.

Los system prompts cortos rinden más que los largos

Los system prompts engordan solos. Alguien añade un párrafo para un caso límite, otro añade tres ejemplos, y un año después cada llamada arrastra 4.000 tokens de instrucciones — la mitad de las cuales el modelo haría bien de todos modos. Audítalo: elimina instrucciones que cubren comportamientos que el modelo ya acierta, colapsa ejemplos redundantes y mueve el material de referencia poco usado a un sistema de recuperación, para pagarlo cuando es relevante en lugar de siempre.

La disciplina de herramientas recorta idas y vueltas ocultas

Las cargas de agente queman tokens en idas y vueltas: cada llamada a herramienta y su resultado vuelven a hacer pasar el contexto acumulado por el modelo. Tres hábitos lo encogen:

• Contratos de herramienta estrechos. Una herramienta que devuelve exactamente lo que el agente necesita gana a una que devuelve el registro completo que el modelo debe cribar — la criba la pagas en cada turno posterior.
• Menos herramientas, mejores. Cada definición de herramienta viaja en el prompt se use o no. Poda las que nada llama.
• Bucles con presupuesto. Da a los agentes un presupuesto explícito de pasos y un comportamiento definido al agotarlo. “Inténtalo hasta que funcione” no es una instrucción; es un grifo abierto.

Ajusta la clase de modelo a la tarea

Anthropic publica modelos en niveles claros de capacidad y precio — a fecha de este artículo, clase Haiku para trabajo rutinario rápido, clase Sonnet para el equilibrio diario, clase Opus para el razonamiento más exigente (verifica nombres y tarifas vigentes en la página de modelos de Anthropic, porque cambian). El patrón que se mantiene generación tras generación: enruta por tarea, no por costumbre. Clasificación, extracción, formateo y primeros borradores no necesitan el nivel superior; el razonamiento arquitectónico profundo, a veces sí. La misma lógica aplica dentro del selector de modelos de Cursor — y los modos de razonamiento extendido merecen el mismo escrutinio, porque los tokens de razonamiento son tokens de salida que pagas, lo necesitara la tarea o no.

Reglas de equipo: donde el ahorro se compone

Los hábitos individuales ahorran dinero real. Los de equipo lo multiplican — porque los modos de fallo caros son organizativos, no personales.

Una fuente de verdad para el conocimiento del stack. Si cada desarrollador reexplica la arquitectura al modelo con sus propias palabras, pagas esa explicación docenas de veces al día — y cada versión difiere un poco. Un archivo de reglas de proyecto mantenido (o un CLAUDE.md, o ambos) se escribe una vez, se versiona en git y se adjunta solo.

Ticket → brief → build. El trabajo que llega a un agente debería llegar como brief: qué cambiar, dónde, qué aspecto tiene el “hecho”, qué no tocar. Los briefs hacen los runs de agente más cortos y más precisos. El ticket vago — “mejora el flujo de checkout” — se convierte en una excavación arqueológica carísima antes de la primera edición.

Una puerta humana antes de los bucles de “arréglalo todo”. Las instrucciones amplias y cuasi destructivas — arregla todos los tests, actualiza todas las dependencias, resuelve cada aviso del linter — necesitan a una persona aprobando el plan primero. Es la misma disciplina de puertas de revisión que aplicamos a los flujos de agente en producción, aplicada a tus propias herramientas.

Mira la factura cada semana, brevemente. No un proyecto de dashboard — diez minutos en la página de uso del proveedor. Los picos de gasto se remontan a un flujo, a un patrón de chat o a un bucle desbocado, y cada uno se arregla en cuanto alguien lo ve. El gasto que nadie mira solo se mueve en una dirección.

Quién debería hacer qué

Fundador u operador en solitario. Adopta primero los hábitos gratis: adjuntos acotados, chat nuevo por tarea, plan antes de bucle, un archivo de reglas. Sáltate la infraestructura — ni gateway ni dashboard. Tu palanca está entera en los hábitos de trabajo, y por sí sola tapa la mayoría de escenarios de factura desbocada.

Equipo de operaciones o producto de cinco personas. Todo lo anterior, más la capa compartida: un archivo de reglas versionado que todos heredan, briefs como norma para el trabajo con agentes, una persona con nombre que mira el uso cada semana. Si tenéis cargas por API, estructura los prompts para la caché antes de optimizar nada más — es la mayor palanca individual y cuesta un refactor, no una plataforma.

Agencia o pod de delivery. El gasto en tokens es margen. Enruta por clase de tarea como política, no como preferencia; haz de la estructura de prompt amigable con la caché un estándar de build; monta atribución por cliente para que el coste se siente al lado del ingreso. En este punto la pregunta deja de ser higiene de herramientas y pasa a ser arquitectura — qué modelo carga con qué flujo, con registro y revisión — y eso es terreno de la Capa Operativa — explicamos qué es una Capa Operativa de IA aparte, con la lógica de presupuesto desarrollada en nuestro desglose de costes de implementación.

La factura es un espejo

El gasto en tokens es una telemetría inusualmente honesta: refleja, línea a línea, cómo trabaja tu equipo de verdad con estas herramientas. El contexto hinchado, los briefs vagos y los bucles sin vigilar aparecen en la factura antes que en ningún otro sitio. Arregla los hábitos y la factura sigue — y, en silencio, también mejora lo que los modelos te devuelven.

Si prefieres un segundo par de ojos — qué flujos queman qué, dónde pagarían el enrutado o la caché, qué aspecto tiene un montaje gobernado para un equipo de tu tamaño —, empieza por un presupuesto Web & eCommerce o US → EMEA.