Cost Engineering, $20 vs. $200 al mes: cómo pagar 10 veces menos por los mismos resultados

Tiempo: ~25 min de teoría + 30 min de práctica

Lo esencial

Entre $20 y $200 al mes no hay 10 veces más trabajo. Lo más común es que haya 10 veces más código sin optimizar.

El mismo chatbot, la misma máquina de contenido, el mismo agente. Un desarrollador paga $200 porque manda todo a Opus, sin caché, en tiempo real, y envía todo el historial en cada solicitud. Otro paga $20 por el mismo resultado porque enruta los modelos según la complejidad, guarda en caché el prompt de sistema y procesa por lotes lo que no es urgente.

Esta lección es un mapa de 9 técnicas de cost engineering. Cada técnica ahorra entre 30% y 99% en su tipo de carga de trabajo. Juntas, bajan la factura de 5 a 10 veces sin perder calidad.

🎨 Imagínalo así: pagar $200 por lo mismo que a tu vecino le cuesta $20 es como ir en taxi de tu casa al café de la esquina dando la vuelta por otra ciudad. Caminando llegas en 10 minutos. Pero la costumbre de apretar "pedir taxi" es un movimiento sin optimizar. Esta lección es el mapa de los atajos.

🎯 Árbol de decisión: ¿vale la pena optimizar ahora?

Antes de dedicar de 4 a 8 horas a la caché y al procesamiento por lotes, comprueba si tiene sentido.

¿Tus costos actuales son >$200/mes?
  → Sí → OPTIMIZA. El retorno es claro.
  → No → ¿Van a subir a más de $200 en 2-3 meses?
    → Sí → Prepara la infraestructura ahora (técnicas 1 + 5)
    → No → No pierdas tiempo. Sigue construyendo funciones.

Regla de recuperación: el ahorro debe ser de más de $100/mes para recuperar el tiempo de configuración (4-8 horas la primera vez + 2-3 horas depurando la invalidación de la caché + 1 hora de mantenimiento trimestral).

🎨 Imagínalo así: poner paneles solares en una cochera donde el foco se prende 10 minutos al día no tiene sentido. Ponerlos en una casa con auto eléctrico se paga en 3 años. Optimizar costos funciona igual: primero crece la factura, después la infraestructura.

Conceptos clave

• Right-sizing: elegir el modelo según la complejidad de la tarea (Haiku → Sonnet → Opus), no "todo al más listo por si acaso"
• Prompt caching: el contexto repetido se guarda en caché por 5 minutos o 1 hora; con un cache hit el precio baja 10 veces o más
• Batch API: procesamiento asíncrono de hasta 100K solicitudes con plazo de hasta 24 horas, con 50% de descuento
• Response caching: la respuesta final del modelo se guarda en KV/Redis; una solicitud repetida devuelve el resultado sin llamar al LLM
• Clasificación con embeddings: las tareas de clasificación se hacen con similitud coseno sobre embeddings, órdenes de magnitud más baratas que una llamada a un LLM
• Disciplina de contexto: administrar la ventana de contexto (RAG, ventana deslizante, resumen) en lugar de "mandamos todo el historial"
• Modelos locales: las tareas típicas (clasificación, traducción, resúmenes) se van a Ollama y el costo se vuelve cero
• Alertas de presupuesto: avisos automáticos en $50/$100/$200 para detectar una anomalía antes de fin de mes

Teoría

Técnica 1: el modelo del tamaño correcto (Haiku vs. Sonnet vs. Opus)

Anthropic tiene varios niveles de modelos con distinto precio: Haiku (tareas simples y rápidas), Sonnet (el modelo de trabajo principal), Opus (tareas complejas) y Fable (las tareas más largas y complejas). Usar Opus para clasificar tickets es como contratar a un consultor de McKinsey para que ordene el correo.

Comparación de precios (por 1M de tokens, a octubre de 2026; precios y versiones vigentes: Lo vigente):

Proporciones (a octubre de 2026):

• Opus 5.5 / Sonnet 5.5: 2x (Opus 4.1 costaba 5 veces más que Sonnet 4): pasar de Opus a Sonnet ahorra menos que antes
• Sonnet 5.5 / Haiku 4.5: 2x en entrada y 2x en salida: pasar de Sonnet a Haiku sigue dando un ahorro notable
• Opus 5.5 / Haiku 4.5: 4x, Fable 5.1 / Haiku 4.5: 10x: el margen principal de ahorro está en usar bien Haiku para las tareas masivas

🎨 Imagínalo así: antes Opus era como un taxi ejecutivo (5 veces más caro que el económico). A octubre de 2026, Opus es un económico plus (solo el doble que Sonnet). El ahorro principal ya no es "deja Opus", sino "no uses Sonnet donde Haiku alcanza".

Regla 80/15/5 (una referencia, no una ley):

• 80% de las tareas deberían ir a Haiku (clasificación, consultas simples, resúmenes breves): aquí está el ahorro principal
• 15% de las tareas, a Sonnet (borradores, código, razonamiento de varios pasos)
• 5% de las tareas, a Opus (decisiones de arquitectura, estrategia compleja, revisión de código crítico): ahora duele menos pagarlo

El enrutamiento en código:

// router.ts — elegir el modelo según el tipo de tarea
type TaskType = "classify" | "summarize" | "draft" | "code" | "architect";

const MODEL_MAP: Record<TaskType, string> = {
  classify: "claude-haiku-4-5",       // barato y rápido
  summarize: "claude-haiku-4-5",      // barato y rápido
  draft: "claude-sonnet-5-5",         // necesita coherencia
  code: "claude-sonnet-5-5",          // necesita exactitud
  architect: "claude-opus-5-5",         // necesita razonamiento profundo
};

function pickModel(task: TaskType): string {
  return MODEL_MAP[task];
}

// Uso
const model = pickModel("classify");
const response = await anthropic.messages.create({
  model,
  max_tokens: 100,
  messages: [{ role: "user", content: userMessage }],
});

Ahorrarás: una parte notable de los costos si enrutas bien (lo principal: las tareas masivas a Haiku, no a Sonnet). Un ejemplo está en el Caso 1 más abajo (las cifras son ilustrativas).

Advertencia importante sobre el tokenizador: los modelos 4.7 y posteriores (incluidos Opus 5.5 y Sonnet 5.5) usan un tokenizador nuevo: el mismo texto da alrededor de 30% más tokens que en Sonnet 4.6 y modelos anteriores (según la documentación de Anthropic a octubre de 2026). Tómalo en cuenta al migrar desde modelos viejos.

Sobre el retiro de modelos de la API: a octubre de 2026 Haiku 4.5 sigue en la API, pero la fecha más próxima posible de retiro es el 15.10.2026. Sigue la página de model deprecations y mantén los nombres de los modelos en un solo lugar del código, como en router.ts arriba.

Técnica 2: Prompt caching (90% de descuento)

El prompt caching de Anthropic consiste en que un bloque de contexto repetido (el prompt de sistema, documentos, brand-voice.md, el contexto del código) se guarda en caché del lado de Anthropic. En la siguiente llamada dentro de 5 minutos, ese bloque cuesta 10 veces menos en entrada (en Opus 5.5 y Fable 5.1 el descuento por leer de la caché es todavía mayor).

Cuándo funciona:

• El bloque no es más corto que el mínimo del modelo (a octubre de 2026: 512 tokens en Sonnet 5.5 y Opus 5.5, 4096 tokens en Haiku 4.5; un bloque más corto no entra en caché)
• El mismo contexto se reutiliza dentro de 5 minutos (TTL por defecto) o de 1 hora (TTL extendido, un poco más caro al escribir)
• Cache hit = coincidencia exacta con el prefijo guardado

Multiplicadores (a octubre de 2026):

Montos concretos para Sonnet 5.5 (entrada base $2/MTok, a octubre de 2026):

Montos concretos para Haiku 4.5 (entrada base $1/MTok):

El write cuesta 25% más, pero el hit es 10 veces más barato que la base. La caché se paga sola después del primer cache hit (5-min) o del segundo (1-hour).

Implementación (Anthropic SDK):

import anthropic

client = anthropic.Anthropic()

# Prompt de sistema grande (más largo que el mínimo de caché): lo guardamos en caché
SYSTEM_PROMPT = """[brand-voice largo + guía de estilo + contexto: 5000 tokens]"""

response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1000,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"}  # caché de 5 min
        }
    ],
    messages=[
        {"role": "user", "content": "Escribe un post sobre X"}
    ]
)

Dónde rinde más la caché (aproximado; depende de qué parte del contexto se repite):

• Chatbot con un prompt de sistema grande (preguntas frecuentes + tono + ejemplos): 70-80% de ahorro
• Asistente de código con el contexto del proyecto: 50-70%
• Sistema RAG con citas de documentos: 40-60%

Ahorrarás: normalmente 40-60% de los costos totales en cargas de trabajo con mucha lectura.

Fuente: platform.claude.com/docs/en/build-with-claude/prompt-caching

Técnica 3: Batch API (50% de descuento)

Con la Batch API de Anthropic envías hasta 100,000 solicitudes en un lote y recibes todas las respuestas en un plazo de 24 horas. El descuento es de 50% en todos los tokens (entrada y salida).

Precios por lote de los modelos vigentes (a octubre de 2026):

Dónde funciona perfecto:

• Generar contenido para un blog (10 artículos para la mañana)
• Traducción masiva
• Resumir un archivo histórico
• Precalcular embeddings (aunque para embeddings hay modelos baratos aparte)
• Probar prompts en distintos modelos

Dónde NO sirve:

• Chat en tiempo real
• Atención a clientes
• Agentes de voz
• Cualquier caso donde el usuario espera respuesta en < 1 minuto

Implementación:

import anthropic

client = anthropic.Anthropic()

# Creamos un lote de 1000 solicitudes de resumen
requests = []
for article in articles:
    requests.append({
        "custom_id": f"article-{article.id}",
        "params": {
            "model": "claude-sonnet-5-5",
            "max_tokens": 200,
            "messages": [
                {"role": "user", "content": f"Resúmelo en 3 viñetas:\n\n{article.text}"}
            ]
        }
    })

batch = client.messages.batches.create(requests=requests)
print(f"Batch ID: {batch.id}, status: {batch.processing_status}")

# Revisamos en una o dos horas
result = client.messages.batches.retrieve(batch.id)
if result.processing_status == "ended":
    # Descargamos los resultados
    for output in client.messages.batches.results(batch.id):
        print(output.custom_id, "".join(b.text for b in output.result.message.content if b.type == "text"))

Ahorrarás: 50% en cualquier trabajo masivo. Ejemplo de cálculo (Sonnet 5.5, a octubre de 2026): 1000 artículos al mes, con ~3000 tokens de entrada y ~200 de salida cada uno. Sin lote son 3M × $2 + 0.2M × $10 = $8; con lote, $4.

Fuente: platform.claude.com/docs/en/build-with-claude/batch-processing

Técnica 4: Modelos locales (Ollama) para tareas típicas

Los modelos de código abierto y de pesos abiertos (familias Llama, Qwen, Gemma, Mistral, DeepSeek, gpt-oss) funcionan localmente con Ollama. Gratis. Sin factura. La lista vigente de modelos y etiquetas está en la biblioteca de Ollama.

🎨 Imagínalo así: un modelo en la nube por API es un auto rentado que se paga por hora. Ollama es tu propia bici en la cochera. En distancias largas la bici pierde; para ir a la tienda, siempre gana.

Hardware (referencias; depende del modelo y de la compresión):

• Unos 16 GB de memoria (Mac con memoria unificada o tarjeta de video de 12 GB) → modelos de 7B-14B
• Unos 32 GB → modelos de hasta 32B
• 64 GB o más, o una tarjeta de video de 24 GB → 70B en versión comprimida (quantized)

Dónde funcionan los modelos locales (en tareas simples, la calidad es cercana a la de la nube):

• Clasificación de textos cortos
• Extracción de entidades (NER)
• Traducciones simples ES↔︎EN, ES↔︎PT
• Resúmenes de documentos cortos
• Análisis de sentimiento
• Detección de intención en un chatbot
• Cambio de formato (JSON → markdown, y al revés)

Dónde NO funcionan (la calidad es claramente menor que en la nube):

• Generación de código de nivel producción
• Razonamiento con contexto largo (>32K tokens)
• Razonamiento complejo de varios pasos
• Textos creativos de alto nivel
• Tool use / function calling complejos

Instalar Ollama:

# Mac (5 minutos)
brew install ollama
ollama serve  # levanta un servidor local en http://localhost:11434

# Descargamos un modelo
ollama pull llama3.3:70b           # ejemplo: ~40GB, tarda de 10 a 30 minutos
ollama pull qwen2.5-coder:32b      # ejemplo: ~20GB, modelo para código
ollama pull qwen3:8b               # ejemplo: un modelo universal pequeño
# modelos y etiquetas recientes en ollama.com/library

# Prueba
ollama run llama3.3 "Clasifica: 'Compré un boleto' → spam/inbox/promo"

Uso mediante una API compatible con OpenAI:

from openai import OpenAI

# Ollama expone un endpoint compatible con OpenAI
local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

response = local.chat.completions.create(
    model="llama3.3:70b",
    messages=[
        {"role": "user", "content": "Clasifica este email: 'Compré un boleto de avión' → spam/inbox/promo"}
    ]
)
print(response.choices[0].message.content)

Ahorrarás: 100% de los costos en las tareas que el modelo local puede resolver. La electricidad no la contamos: una laptop bajo carga consume del orden de 30W, centavos al mes.

Ver la lección Modelos de IA locales para profundizar en los modelos locales.

Fuente: ollama.com

Técnica 5: Response caching (KV / Redis)

Si el 30% de tus solicitudes se repite (preguntas típicas de soporte, traducciones estándar, las preguntas frecuentes de siempre), guarda en caché la respuesta final en un almacén KV o en Redis.

La lógica:

// hash de la solicitud → búsqueda en KV → si existe, devolvemos lo guardado; si no, llamamos al LLM y guardamos
import { createHash } from "crypto";

async function getCachedOrCall(userMessage: string, env: Env): Promise<string> {
  const key = createHash("sha256").update(userMessage.toLowerCase().trim()).digest("hex");

  // 1. Búsqueda en KV
  const cached = await env.RESPONSE_CACHE.get(key);
  if (cached) {
    console.log("Cache HIT");
    return cached;
  }

  // 2. Cache miss: llamamos al LLM
  const response = await callClaude(userMessage);

  // 3. Lo guardamos por 30 días
  await env.RESPONSE_CACHE.put(key, response, { expirationTtl: 60 * 60 * 24 * 30 });

  return response;
}

Precios de Cloudflare KV: tiene un plan gratis con límites diarios de lecturas y escrituras, y lo que pase de esos límites se paga; revisa los límites y precios vigentes en la página de precios de Cloudflare.

La mayoría de los proyectos se quedan dentro del plan gratis.

Dónde funciona:

• Chatbot de atención a clientes (preguntas típicas ~30%)
• Traducciones a varios idiomas de frases estándar
• Autocompletado de búsqueda
• "Productos similares / recomendaciones", si son estables

Ahorrarás: hasta 30-50% de los costos si tu carga de trabajo es repetitiva.

🎨 Imagínalo así: un restaurante con menú. ¿El chef prepara cada platillo desde cero? Caro. Las salsas y bases preparadas de antemano (mise en place) son el response cache. Lo mismo aquí: las preguntas repetidas se preparan una vez y se sirven del refrigerador.

Técnica 6: embeddings en lugar de un LLM para clasificar

La tarea "¿a qué categoría pertenece este texto?" no necesita un LLM. Basta con embeddings + similitud coseno.

Comparación (a octubre de 2026):

Los embeddings cuestan órdenes de magnitud menos que Sonnet 5.5 en entrada, sin contar la salida (que aquí no existe).

La lógica:

from openai import OpenAI
import numpy as np

client = OpenAI()

# 1. Calculamos de antemano los embeddings de las categorías
CATEGORIES = {
    "spam": "Mensajes publicitarios, estafas, phishing, ofertas no deseadas",
    "billing": "Preguntas sobre pagos, facturas, reembolsos, suscripción",
    "tech": "Problemas técnicos, bugs, una función que no sirve",
    "feature": "Solicitud de una función nueva, sugerencia, idea",
}

def embed(text: str) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=text)
    return np.array(r.data[0].embedding)

category_embeddings = {name: embed(desc) for name, desc in CATEGORIES.items()}

# 2. Clasificación de un mensaje nuevo
def classify(message: str) -> str:
    msg_emb = embed(message)
    similarities = {
        name: np.dot(msg_emb, emb) / (np.linalg.norm(msg_emb) * np.linalg.norm(emb))
        for name, emb in category_embeddings.items()
    }
    return max(similarities, key=similarities.get)

print(classify("No puedo entrar a mi cuenta"))  # → "tech"

Ahorrarás: cerca de 99% en clasificación frente a hacerlo con un LLM. Un caso con 100K clasificaciones al mes (promedio de 30 tokens de entrada + 5 de salida):

• Con Sonnet 5.5: ~$6/mes de entrada + $5/mes de salida ≈ $11/mes
• Con Haiku 4.5: ~$3/mes de entrada + $2.50/mes de salida ≈ $5.50/mes
• Con embeddings: unos centavos al mes (la entrada son los mismos ~3M de tokens, al precio de un modelo de embeddings)

Los embeddings ganan por mucho incluso frente al Haiku 4.5, que es el más barato.

Ver la lección RAG para profundizar en RAG y embeddings.

Técnica 7: streaming + parada temprana

Si el resultado puede ser más corto que max_tokens, usa streaming con condiciones de parada. Los tokens de salida cuestan 5 veces más que los de entrada: recortar la salida conviene.

Ejemplo: un clasificador que devuelve una palabra. Sin streaming pones max_tokens=10 "por si acaso". Con streaming + stop="\n", el modelo entrega una palabra y se detiene.

with client.messages.stream(
    model="claude-haiku-4-5",
    max_tokens=10,
    stop_sequences=["\n", ".", ","],  # parar en cualquier separador
    messages=[
        {"role": "user", "content": "Categoría en una palabra: 'No puedo entrar'"}
    ]
) as stream:
    for text in stream.text_stream:
        print(text, end="")

Ahorrarás: 20-40% en tokens de salida cuando el resultado es corto.

Técnica 8: disciplina con la ventana de contexto

El error más común de quien empieza: "resolvamos el problema mandando más contexto". Cada solicitud nueva vuelve a pagar todo el historial acumulado, así que la factura de una conversación larga crece más rápido que la conversación misma.

Antipatrón:

# ❌ MAL: mandamos todo el historial en cada solicitud
messages = []
for turn in conversation_history:  # pueden ser 100+ turnos
    messages.append({"role": turn.role, "content": turn.text})
messages.append({"role": "user", "content": new_message})
# Resultado: 50K tokens de entrada en cada respuesta → ~$0.10 por turno (Sonnet 5.5, a octubre de 2026) → ~$10 por una conversación de 100 turnos

Lo correcto:

# ✅ BIEN: ventana deslizante + resumen
def build_context(history, new_message):
    # Los últimos 10 turnos completos
    recent = history[-10:]

    # Los turnos viejos se resumen (o se usa RAG)
    if len(history) > 10:
        old_summary = summarize(history[:-10])  # se hace una vez y se guarda en caché
        messages = [{"role": "system", "content": f"Contexto:\n{old_summary}"}]
        messages.extend(turn.to_message() for turn in recent)
    else:
        messages = [turn.to_message() for turn in history]

    messages.append({"role": "user", "content": new_message})
    return messages

Técnicas de disciplina de contexto:

• Ventana deslizante: los últimos N mensajes
• Resumen: la parte vieja → un solo bloque compacto
• RAG: traer solo los fragmentos relevantes, no mandar toda la base de conocimiento
• /compact: en Claude Code comprime a mano el historial de la sesión; cuando la ventana de contexto se llena, la compresión también se activa sola (el umbral se configura con el comando /autocompact)

Ahorrarás: 50-70% de los costos en conversaciones largas.

Técnica 9: saltar entre planes gratis (con ética, no para producción)

Los planes gratis existen, pero solo para prototipos y proyectos personales, no para producción:

Las condiciones de los planes gratis de hostings y APIs cambian seguido: revisa la página de precios antes de construir sobre ellos. Precios y versiones vigentes: Lo vigente.

Ética y límites:

• Producción requiere un SLA, y los planes gratis no lo dan
• Riesgo de bloqueo por uso comercial donde lo gratis es solo para uso personal
• Lee con cuidado los términos de servicio
• No uses un plan gratis como infraestructura permanente: no es justo con el proveedor y es inestable

Ahorrarás: 100% durante la fase de exploración. Después busca un plan de pago con un SLA adecuado.

Casos de ahorro

Las cifras de los casos siguientes son ilustrativas: son cálculos para practicar, no mediciones de proyectos reales. Los precios de los modelos son a octubre de 2026.

Caso 1: línea de contenido (blog de una agencia inmobiliaria)

Ahorro: 80% ($145/mes = $1740/año)

Desglose del ahorro: lo que más aporta no son los modelos más baratos en sí (Opus ahora solo cuesta el doble que Sonnet, no es crítico), sino Haiku 4.5 en las tareas masivas de etiquetado + Batch API de noche + prompt cache sobre brand-voice.md.

Caso 2: bot de atención a clientes

Ahorro: 70% ($175/mes = $2100/año)

El motor principal: embeddings en lugar de un LLM para el enrutamiento.

Caso 3: soporte por voz (ver la lección Call Support AI)

Ahorro: 58% por minuto ($180 al mes con 1,000 minutos, $900 al mes con 5,000 minutos)

Los $0.05/min del marketing son solo la tarifa de plataforma de Vapi: el reconocimiento, el LLM, la voz y la telefonía se pagan aparte según los precios de cada proveedor (a octubre de 2026), así que el precio final del minuto depende del stack que elijas.

Herramientas para monitorear costos

Sin monitoreo, optimizar es ir a ciegas. Instala esto desde el día 1.

Límite de gasto en Anthropic Console: Settings → Billing → Spend limits → Adjust limit. Se pone un solo límite: un tope mensual por debajo del tope de tu nivel. Cuando se alcanza, la API devuelve un error hasta que subas el límite (o empiece el mes siguiente), así que ponlo con margen por encima de tu factura normal. Los avisos en $50 y $100 hazlos tú: un script que una vez al día lea el gasto de la página Usage, o un reporte diario como el de la sección siguiente.

Disciplina de presupuesto (reglas de trabajo)

• Revisión diaria del presupuesto: compruébalo automáticamente al inicio del día. Si ya vas en 80% del límite mensual, pausa o escala a una persona
• Presupuesto por función: cada función tiene un presupuesto explícito. "Bot de soporte: máximo $50/mes", escrito en el README y con seguimiento
• Detección de anomalías: un pico de más de 2x el gasto diario promedio: investígalo en menos de una hora
• Revisión trimestral de costos: qué creció en el trimestre, qué se puede quitar, qué funciones gastan de más

🎨 Imagínalo así: una cuenta bancaria sin estados de cuenta no son finanzas, es adivinación. Lo mismo con los costos de LLM: sin monitoreo no administras, solo tienes esperanza.

Antipatrones (NO lo hagas)

• ❌ Usar Opus para todo "para ir a la segura"
• ❌ Mandar todo el historial en cada solicitud (usa resúmenes)
• ❌ No usar prompt cache cuando hay un contexto repetido de >1024 tokens
• ❌ Tiempo real cuando sirve la Batch API (retraso de 24 h vs. 50% de ahorro)
• ❌ Llamadas a la API escondidas en un ciclo sin revisar el presupuesto (puedes quemar $500 en una noche)
• ❌ Saltar entre planes gratis en producción (sin SLA, riesgo de bloqueo)
• ❌ Optimizar cuando la factura es de $20/mes (el retorno es negativo por el tiempo de configuración)
• ❌ No poner límite de gasto ni avisos (te enterarás de una factura de $800 hasta inicio de mes)

Por nivel (por dónde empezar)

Principiante (factura de $20-50/mes, aprendiendo):

• Técnica 1 (modelo del tamaño correcto): cubre 40-50% del gasto de más
• Técnica 8 (disciplina de contexto): cubre otro 20-30%
• Total: -50-70% de costos con 2 horas de trabajo

Intermedio (factura de $50-200/mes, en producción):

• • Técnica 2 (prompt caching): sobre 40-60% del costo de entrada
• • Técnica 3 (Batch API): donde no hace falta tiempo real
• • Técnica 5 (response cache): en las tareas típicas
• Total: -50% adicional

Profesional (factura de $200+/mes, escalando):

• Las 9 técnicas
• Monitoreo con Langfuse/LangSmith
• Alertas de presupuesto configuradas
• Revisión trimestral de costos en el calendario
• Disciplina de producción = costos predecibles

El costo oculto de "ahorrar"

El cost engineering es trabajo. Tómalo en cuenta:

Regla de retorno: el ahorro debe ser de más de $100/mes para recuperar el tiempo de configuración (8 h × $50/h = $400 de una sola vez, que se recuperan en 4 meses).

🎨 Imagínalo así: afilar el hacha antes de talar el bosque tiene sentido cuando vas a talar todo el día. No tiene sentido para cortar un solo árbol.

Lista de verificación (✅)

Al terminar la lección deberías tener:

• Claro cuáles 3 de las 9 técnicas te dan a ti el mayor efecto (depende de tu carga de trabajo)
• Un límite de gasto en Anthropic Console y tus propios umbrales de aviso ($50 / $100 / $200, por ejemplo)
• Tu gasto del mes a la fecha por proveedor (Anthropic, OpenAI, Voyage, la electricidad de Ollama)
• Separación de modelos por complejidad de tarea (en el código o en el prompt de sistema del orquestador)
• Identificadas las 3 funciones que más tokens consumen (con Langfuse, LangSmith o un análisis manual)
• El árbol de decisión aplicado: "¿optimizo ahora o construyo funciones?"

Herramientas y recursos

• claude.com/pricing: planes de suscripción y precios de API
• platform.claude.com/docs/.../pricing: documentación completa de la API con precios
• Lo vigente: resumen de los modelos y precios vigentes de nuestro curso
• Documentación de prompt caching: documentación oficial de cache_control
• Documentación de Batch API: procesamiento masivo con 50% de descuento
• Anthropic Console: pestaña de uso + límites de gasto
• OpenAI Usage: lo mismo para un stack de OpenAI
• Ollama: modelos locales en 5 minutos (Llama, Qwen, Gemma, gpt-oss y otros)
• Helicone: observabilidad de LLM; desde marzo de 2026 en modo de mantenimiento
• LangSmith: trazas y costo por traza
• Langfuse: alternativa de observabilidad de código abierto
• PromptLayer: versionado de prompts + analítica

Conclusiones clave

Entre $20 y $200 al mes no hay 10 veces más trabajo: es la diferencia entre código sin optimizar y código optimizado. Las mismas funciones, la misma confiabilidad, 10 veces más barato: es cuestión de disciplina, no de talento.

3 técnicas cubren 70% del potencial de ahorro: el modelo del tamaño correcto (regla 80/15/5), prompt caching sobre el contexto repetido y la disciplina con la ventana de contexto. Las otras 6 técnicas son para equipos de nivel producción con facturas de $200+/mes.

Optimiza cuando la factura pase de $200/mes o vaya en camino. Antes, es perder el tiempo: configurar la caché cuesta 8 horas y ahorra $20/mes, un retorno negativo. Primero las funciones, después la optimización.

Siguiente lección

→ Graduation: el cierre de la primera parte. Sobre observabilidad, alertas y respuesta a incidentes para aplicaciones con LLM: Production Observability