Optimización de tokens con Claude — cómo bajamos el coste 8× sin perder calidad

Cuando lanzamos la primera versión del redactor de IA en Agentikas, cada post generado costaba 25 céntimos. Tres versiones por post (blog, LinkedIn, X), traducción a inglés, brand review — cuando un autor publicaba dos veces a la semana en dos idiomas, la factura mensual se acercaba a los tres dígitos por usuario. Para una plataforma sin ánimo de lucro y gratuita en su tier base, eso era insostenible.

Hoy ese mismo post cuesta 3 céntimos. La calidad subió, no bajó. Estos son los cuatro patrones que hicieron la diferencia.

1. Prompt caching de las skills y el BRAND

El primer error fue trivial pero caro. Cada generación enviaba como contexto:

• El BRAND.md del blog (~1.500 tokens)
• La skill correspondiente — blog-writer.md, linkedin-writer.md, x-writer.md (~2.000 tokens cada una)
• El design-system.md (~3.000 tokens)
• El prompt del usuario (~200 tokens)

Total: ~6.700 tokens de input por generación, de los cuales 6.500 eran idénticos entre llamadas. Estábamos pagando por reenviar el mismo contexto cada vez.

El fix está en la API de Anthropic: prompt caching. Marcas un bloque del system prompt como cacheable, y las siguientes llamadas dentro de los próximos 5 minutos pagan ~10% del coste de input por ese bloque.

const messages = await anthropic.messages.create({
  model: "claude-haiku-4-5",
  system: [
    {
      type: "text",
      text: BRAND_MD + DESIGN_SYSTEM_MD + BLOG_WRITER_SKILL,
      cache_control: { type: "ephemeral" }, // ← la línea mágica
    },
  ],
  messages: [{ role: "user", content: userPrompt }],
});

Coste de la primera generación: el normal. Coste de las siguientes en los próximos 5 minutos: ~10% del input cacheado. Cuando un autor genera blog + LinkedIn + X + traducción de los tres = 6 llamadas en 30 segundos, el ahorro es del 50% solo con esto.

Una nota importante: el cache TTL es de 5 minutos por defecto. Si el autor pausa media hora y vuelve, el cache se evapora y vuelves a pagar. Para flujos batch (publicar todos los posts de la cola en una pasada), agrupar generaciones cercanas en el tiempo es lo que mejor explota el cache.

2. El modelo correcto para cada tarea

Segundo error: usábamos Claude Sonnet 4.6 para todo. Generación de post, brand review, traducción, generación de slug. Sonnet es el sweet spot de calidad/precio para tareas creativas; es overkill para "convierte 'Cómo construir un blog AI-first' en un slug seguro para URLs".

El cambio: downgrade controlado a Haiku 4.5 para tareas estructuradas y mantener Opus o Sonnet solo para creativas.

TareaModeloPor qué Generar el cuerpo del postSonnet 4.6Calidad de escritura, voz, narrativa Adaptar a LinkedIn / XHaiku 4.5Reformulación corta, alta volumen Generar slug, meta description, tagsHaiku 4.5Output estructurado, alta restricción Traducir post completoSonnet 4.6Calidad de traducción, terminología Brand review (LLM, opcional)Haiku 4.5Validación, no creación

Haiku cuesta ~5× menos por token que Sonnet. Para las tareas donde calidad creativa no aporta valor, el downgrade es invisible para el usuario y enorme para la factura.

3. Tool use estricto = cero reintentos

Cuando una generación devolvía malformada — markdown donde esperabas HTML, comilla suelta — el código hacía un retry con un prompt extra "por favor devuélvelo en formato correcto". Eso duplicaba el coste de esa generación. Para una de cada veinte, era ruido. Cuando el usuario era prolífico, era el 5% de la factura completa.

El patrón que lo elimina es tool use con JSON Schema estricto (lo cubrimos en otro post de prompt engineering). Defines la forma exacta del output, el modelo se compromete a respetarla, los retries por malformado caen a cero.

Aparte del ahorro de retries, el modelo procesa más rápido cuando sabe la forma exacta del output. La latencia baja un 20-30% en mediciones nuestras, y en pago por token-out, eso son menos tokens emitidos en respuesta vacía o decorativa.

4. Batching y paralelización inteligente

Cuando un autor hace clic en "publicar", la plataforma genera tres versiones del contenido. Antes lo hacíamos secuencial: generar blog → terminar → generar LinkedIn → terminar → generar X. Tiempo total: ~90 segundos.

El cambio fue paralelizar las tres generaciones. Cada una es independiente — usa el mismo BRAND y design-system pero con skill distinta. Lanzas las tres en paralelo:

const [blog, linkedin, x] = await Promise.all([
  generateBlog(topic, brand),
  generateLinkedIn(topic, brand),
  generateX(topic, brand),
]);

Tiempo total: ~30 segundos (el más lento). El usuario no espera. Pero hay un detalle no obvio: las tres llamadas comparten el cache del BRAND y design-system si las haces dentro de la misma ventana de 5 minutos. La primera paga el cache; las dos siguientes pagan ~10% del input cacheado. Paralelización + cache = win compuesto.

El resultado, en una factura mensual

Para un autor activo (3 posts/semana, dos idiomas, todas las plataformas):

• Antes: ~$45/mes en Claude por usuario
• Ahora: ~$5/mes en Claude por usuario

Eso se traduce en que la plataforma puede absorber el coste de un volumen mucho mayor de usuarios sin cambiar el modelo (gratis en el tier base, sostenible para Agentikas Labs como entidad sin ánimo de lucro).

El ahorro no vino de un truco — vino de cuatro patrones independientes que se componen. Cualquier proyecto que use Claude API a escala debería tenerlos los cuatro encendidos. La diferencia entre tener uno o todos es el factor 8 que separa una factura sostenible de una que no lo es.

---

Las técnicas de prompt caching están documentadas en la documentación oficial de Anthropic. El runtime de Agentikas que las aplica está en @agentikas/ai, parte del monorepo open source.