Programar con IA sin gastar de más

Casi todo lo que se escribe sobre programar con inteligencia artificial trata sobre qué modelo es mejor. En la práctica, cuando llega la factura, el modelo elegido explica una parte menor del total. Lo que la explica es cuántas veces volviste a mandar la misma información.

Este artículo es sobre eso: qué se paga exactamente, y qué prácticas bajan el gasto sin empeorar el resultado. Los ejemplos usan dos modelos de Anthropic —Claude Sonnet 5 y Claude Opus 5— porque cubren los dos extremos del problema, pero el razonamiento sirve para cualquier proveedor.

Qué se paga

Un modelo de lenguaje cobra por tokens: fragmentos de texto de unos cuatro caracteres. “programar” es un token; “internacionalización” son varios. Se cobran por separado los que entran y los que salen:

Modelo	Entrada por millón	Salida por millón	Contexto
Claude Sonnet 5	2 USD	10 USD	1M tokens
Claude Opus 5	5 USD	25 USD	1M tokens

Opus cuesta exactamente 2,5 veces lo que cuesta Sonnet, en entrada y en salida. Y la salida cuesta cinco veces más que la entrada en los dos.

Ahora el dato que cambia todo: una conversación no tiene memoria. Cada vez que el modelo responde, el programa vuelve a enviarle toda la conversación anterior. En el turno veinte no estás pagando veinte mensajes: estás pagando la suma de todos los prefijos, que crece de forma cuadrática. Una sesión larga de programación puede costar más que veinte sesiones cortas con el mismo contenido.

Por eso la primera pregunta útil no es qué modelo usar, sino qué le estoy mandando y cuántas veces.

1. Caché de contexto: la única mejora sin contrapartida

Es lo primero que hay que hacer, antes que cualquier otra cosa, porque no implica ninguna decisión difícil.

Si le mandás repetidamente el mismo bloque de texto —las instrucciones del sistema, la documentación del proyecto, el archivo sobre el que estás trabajando— el proveedor puede guardarlo procesado y reutilizarlo. En la API de Anthropic esa función se llama prompt caching, y los números son estos:

• Escribir en la caché la primera vez: 1,25 veces el precio normal.
• Leer de la caché las veces siguientes: una décima parte del precio normal.

Es decir, a partir del segundo uso pagás el 10 % por esa porción. Con un contexto de 50.000 tokens que se repite treinta veces, la diferencia entre usar la caché y no usarla es aproximadamente diez a uno.

El detalle que hace que no funcione. La caché coincide por prefijo: se reutiliza mientras el comienzo del pedido sea idéntico byte por byte. Un solo carácter distinto al principio invalida todo lo que viene después. Los invalidadores más comunes son:

• Una marca de fecha y hora en las instrucciones del sistema.
• Un identificador aleatorio por pedido.
• Un objeto JSON serializado sin ordenar las claves.
• Una lista de herramientas que cambia de orden entre llamadas.

La regla práctica es poner lo estable primero y lo que varía al final. Y se verifica sin adivinar: la respuesta de la API trae un campo cache_read_input_tokens. Si es cero cuando debería haber coincidencia, hay un invalidador en el prefijo.

const r = await client.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 16000,
  cache_control: { type: "ephemeral" },
  system: contextoDelProyecto,   // estable: se cachea
  messages: [{ role: "user", content: preguntaDeAhora }],  // variable: al final
});

console.log(r.usage.cache_read_input_tokens); // si es 0, algo rompió el prefijo

2. Antes de cambiar de modelo, probá bajar el esfuerzo

La reacción intuitiva ante una factura alta es pasar todo al modelo más barato. Suele ser peor negocio de lo que parece, por dos razones.

La primera: la caché es por modelo. Si repartís el trabajo entre Sonnet y Opus, cada uno mantiene su propia caché. Un mismo contexto que se reutilizaba treinta veces pasa a reutilizarse quince en cada lado, y hay que pagar la escritura inicial dos veces. Podés terminar gastando más que antes.

La segunda: existe una palanca intermedia. Los modelos actuales aceptan un nivel de esfuerzo (effort), que regula cuánto razona el modelo antes de responder: de low a max. Es una decisión distinta de elegir modelo, y en la práctica el modelo más capaz con esfuerzo bajo suele rendir igual o mejor que uno más chico con esfuerzo alto — a un costo comparable, y sin partir la caché en dos.

El orden correcto para probar es este:

1. Activar la caché. Sin contrapartida.
2. Bajar el esfuerzo en las rutas donde la calidad se mantiene.
3. Recién entonces, evaluar un modelo más económico.

Para programar, high suele ser el punto de equilibrio y xhigh el que conviene cuando la tarea es larga y con muchos pasos. low está bien para trabajo mecánico: renombrar, reformatear, traducir un archivo de configuración.

3. Medí el costo por tarea terminada, no por pedido

Este es el error de razonamiento más caro, y el menos evidente.

Si comparás dos modelos por lo que cuesta una llamada, el más barato siempre gana. Pero un modelo que necesita cuatro intentos para producir código que compila no es más barato que uno que lo resuelve en uno solo — es 1,6 veces más caro, y además te consumió a vos el tiempo de revisar los tres intentos fallidos.

La unidad correcta es el costo de completar la tarea: todos los turnos, todos los reintentos, todo el contexto reenviado hasta que el resultado sirve. Medido así, el ranking cambia seguido.

Y hay un costo que no aparece en ninguna factura: el tiempo de quien revisa. Si el código llega con errores sutiles, alguien los busca. Ese rato vale bastante más que la diferencia entre 2 y 5 dólares por millón de tokens.

4. Lo que no es interactivo va por lotes

Si el resultado no lo estás esperando en pantalla —documentar un módulo completo, generar pruebas para cincuenta archivos, clasificar tickets—, la Batch API procesa los pedidos de forma asincrónica al 50 % del precio.

Tarda más y no sirve para trabajo conversacional. Para todo lo demás, es una reducción a la mitad sin ninguna consecuencia.

5. Prácticas que además mejoran el resultado

Estas no son técnicas de ahorro: son formas de trabajar mejor que, como efecto secundario, gastan menos. Y son las que más diferencia hacen en el día a día.

Empezá conversaciones nuevas. Cuando terminás una tarea y arrancás otra, no sigas en el mismo hilo. Todo lo anterior se sigue reenviando en cada turno, y además compite por la atención del modelo con lo que importa ahora.

Dá el error, no la descripción del error. Pegar el mensaje del compilador o la salida de la prueba que falla es más corto que explicar qué pasa, y mucho más preciso. Un mensaje de error son cincuenta tokens que valen más que quinientos de descripción.

No pegues el repositorio entero. Es tentador dar todo el contexto por las dudas. Pero un modelo con veinte archivos irrelevantes rinde peor que uno con los tres que corresponden: el ruido compite con la señal, y encima lo pagás en cada turno de la conversación.

Pedí el diff, no el archivo. Si pedís “reescribí este archivo”, la salida es el archivo completo — y la salida cuesta cinco veces más que la entrada. Pedir solo las líneas que cambian recorta esa parte de la factura y además hace la revisión más fácil.

Escribí primero la prueba. Darle una prueba que falla convierte una instrucción ambigua en un criterio verificable. Reduce los intentos, que es donde se va la plata, y te deja algo útil aunque el modelo se equivoque.

Cuándo directamente no conviene

Un modelo de lenguaje no es la herramienta correcta para todo, y forzarlo cuesta dinero y tiempo:

• Renombrar, reformatear, reemplazos mecánicos. El refactor de tu editor lo hace de forma exacta, instantánea y gratis.
• Cualquier cosa que un tipo de dato pueda garantizar. Si el compilador puede demostrarlo, no hace falta que un modelo lo revise.
• Decidir la arquitectura de un sistema que todavía no existe. Sin el contexto de tu organización, tus plazos y tu equipo, la respuesta va a ser una descripción genérica de buenas prácticas.

En resumen

El gasto casi nunca viene de haber elegido el modelo caro. Viene de reenviar el mismo contexto sin caché, de arrastrar conversaciones eternas, y de contar llamadas en lugar de contar tareas terminadas.

Si tuviera que quedarme con dos cosas: activá la caché de contexto y medí lo que cuesta terminar una tarea, no lo que cuesta un pedido. Las dos son gratis de implementar y explican la mayor parte de la diferencia.