Cómo ahorrar en APIs de IA con enrutamiento inteligente

La factura de APIs de IA crece rápido. Un equipo pequeño que integra Claude, GPT-5 y Gemini en una app puede pasar de 200 € al mes a 2.000 € en cuestión de un trimestre sin hacer nada especial — solo porque cada feature nueva empuja el consumo. Cuando llegas a ese punto, tienes dos opciones: subir precios al cliente final o reducir coste de inferencia.

Este artículo es sobre la segunda. Específicamente, sobre una técnica que rara vez se explica con detalle: enrutamiento inteligente. Mandar cada petición al modelo más barato que pueda hacerla bien, cachear lo que se repite, añadir fallbacks cuando un proveedor falla, y facturar solo lo que consumes.

Es parte de la guía completa de BYOK y multi-proveedor en IA. Aquí bajamos al detalle técnico de la capa de optimización.

El problema: "un modelo para todo" es caro

La forma intuitiva de integrar una API de IA es elegir un modelo y enviarlo todo. Pero la diferencia de precio entre modelos de una misma familia es enorme. A abril de 2026, los precios oficiales en input por millón de tokens:

Entre el más barato y el más caro de una misma familia hay entre 10× y 150× de diferencia. Si mandas absolutamente todo al modelo premium, pagas 10-150× más de lo estrictamente necesario — porque la mayoría de las peticiones no requieren ese nivel.

Ejemplo típico de un chatbot empresarial:

• 60% son saludos, confirmaciones, "sí", "no", clarificaciones → Nano / Flash-Lite / Haiku sobran.

• 30% son consultas medias (resumir, clasificar, extraer datos) → Mini / Flash / Haiku.

• 10% son tareas complejas (razonamiento, código largo, análisis profundo) → GPT-5 / Sonnet / Gemini Pro.

• Menos del 1% requieren Opus o equivalente.

Si pones todo en Opus 4.7, pagas 15 € por millón cuando el 60% del tráfico debería costar 1 € y el 30% debería costar 3 €. La factura se multiplica por 5-10× sin ganar calidad en la mayoría de respuestas.

Los cuatro patrones de optimización

Hay cuatro técnicas que, combinadas, pueden bajar una factura de APIs de IA entre un 50% y un 90% sin tocar la UX:

1. Enrutamiento por complejidad: elegir modelo por petición.

2. Prompt caching: pagar una vez por contexto reutilizado.

3. Fallbacks y retries: cuando un proveedor falla, ir al siguiente sin caer.

4. Batching y async: para workloads no-tiempo-real, usar el pricing batch (50% descuento).

Las explico en orden.

Patrón 1: enrutamiento por complejidad

El router es una capa previa a la llamada al LLM. Recibe la petición, clasifica la dificultad (reglas o un modelo pequeño como clasificador) y decide a qué modelo ir.

Pseudocódigo típico:

async function route(userMessage, history) {
  const difficulty = await classify(userMessage, history)

  if (difficulty === "trivial")   return callHaiku(userMessage)
  if (difficulty === "medium")    return callSonnet(userMessage)
  if (difficulty === "hard")      return callOpus(userMessage)
}

La función classify puede ser:

• Reglas: si el mensaje tiene menos de 50 tokens y no contiene palabras clave ("explica", "analiza", "código"), es trivial. Imperfecto pero gratis.

• Clasificador ligero: un modelo pequeño (Haiku 4.5 o Gemini Flash-Lite) que en 100ms decide la categoría. Añade 0,001 € por petición pero suele acertar >90% de los casos.

• Híbrido: reglas para lo obvio, clasificador para lo dudoso.

Ejemplo real: reducción del 72% en un soporte técnico

Una startup SaaS de 40 empleados integró enrutamiento en su chatbot de soporte:

• Antes: 100% a Claude Sonnet 4.6. Factura: 1.800 €/mes.

• Después: 65% a Haiku, 25% a Sonnet, 10% a Opus. Factura: 500 €/mes. Calidad percibida: idéntica según encuestas internas.

Reducción real: 72% sin tocar el producto.

La clave fue: saludos, confirmaciones, "cómo reseteo la contraseña", "qué horario tenéis" → Haiku resolvía perfectamente. Solo las incidencias técnicas complejas iban a Sonnet, y los troubleshootings muy raros a Opus.

Patrón 2: prompt caching

Cuando tu app repite el mismo contexto en cada petición — system prompt, documentación, historial largo — estás pagando input tokens que no cambian. El prompt caching permite pagar una vez por ese bloque y reutilizarlo a precio reducido.

Precios de caching en abril 2026:

• Anthropic: cache write cuesta 1,25× el input base (TTL 5 min) o 2× (TTL 1 hora). Cada cache hit cuesta 0,1× el input base, es decir un 90% de descuento. Fuente: platform.claude.com/docs/en/build-with-claude/prompt-caching.

• OpenAI: GPT-5 aplica descuento automático de ~90% sobre input cacheado. No necesita declararlo explícitamente; el sistema detecta repetición.

• Google: Gemini soporta context caching con pricing reducido similar.

Cuándo compensa

Regla práctica de Anthropic: el break-even con TTL 5 min está en una sola lectura. Si vas a usar el contexto cacheado más de una vez en 5 minutos, ya ahorras. Con TTL 1 hora, break-even en dos lecturas.

Casos típicos donde caching dispara el ahorro:

• RAG con documentación estable: si tu chatbot siempre consulta el mismo manual de 80.000 tokens, cachéalo. Cada conversación ahorra ~72 € por cada millón de tokens procesados.

• Agentes multi-turno: el system prompt del agente + las primeras 5-10 interacciones son estables dentro de la sesión. Cachearlo baja el coste de cada turno siguiente al 10%.

• Plantillas con ejemplos few-shot: si repites 20 ejemplos en cada petición, son input duplicado.

Ejemplo real: chatbot RAG con documentación corporativa

Un equipo de soporte con RAG sobre 50 MB de documentación (≈120.000 tokens) pasó de:

• Sin caching: 3,60 € por conversación promedio.

• Con caching (Anthropic, TTL 1h): 0,72 € por conversación.

Reducción: 80%. El write inicial del cache (sobrecoste del 2×) se amortiza al tercer turno.

Patrón 3: fallbacks y retries multi-proveedor

Los proveedores caen. OpenAI ha tenido tres incidentes >30 min en los últimos 12 meses; Anthropic dos; Google uno. Si toda tu app depende de un solo proveedor, cada caída equivale a downtime.

Un fallback multi-proveedor manda la petición al proveedor primario, y si responde con 5xx, 429 (rate limit) o timeout, reintenta automáticamente en el secundario. Sin intervención.

routing:
  primary: anthropic/claude-sonnet-4.6
  fallback:
    - openai/gpt-5
    - google/gemini-2.5-pro
  conditions:
    - http_5xx
    - rate_limit_429
    - timeout_10s

Beneficios:

• Uptime: tu app sigue funcionando en caídas de un proveedor.

• Rate limits: si Anthropic te rate-limita, OpenAI absorbe el pico.

• Coste: puedes poner el modelo barato como primario y el caro como fallback, ahorrando en el 99% de las peticiones y pagando extra solo cuando hay problema.

Herramientas que lo implementan out-of-the-box:

• LiteLLM (open-source, self-hosted): soporta fallback chains, retries con backoff, cooldown logic. Doc oficial: docs.litellm.ai.

• Portkey (managed, desde 49 $/mes): guardrails, fallbacks declarativos, observabilidad.

• OpenRouter (managed): el más simple, una API para 200+ modelos. Añade 5-15% markup sobre precio del proveedor.

• Levante Platform: AI Gateway con una sola API key y Zero Data Retention bajo infraestructura europea.

Si priorizas soberanía europea y RGPD, el gateway self-hosted (LiteLLM) o uno con infraestructura EU (Levante Platform) son las opciones viables. OpenRouter y Portkey corren en US.

Patrón 4: batch processing

Si tu workload no requiere respuesta en tiempo real — clasificar miles de tickets, generar resúmenes nocturnos, reetiquetar documentos — puedes usar el modo batch que OpenAI y Anthropic ofrecen desde 2025.

Detalles:

• OpenAI Batch API: 50% de descuento sobre input y output. Respuestas en ventana de 24h.

• Anthropic Message Batches: 50% descuento. Hasta 100.000 peticiones por batch.

Uso típico:

# En vez de procesar 10.000 tickets con llamadas individuales
# (coste A, latencia X), subes un batch .jsonl y pagas la mitad.

# Coste en síncrono: 10.000 × 0,002 € = 20 €
# Coste en batch: 10.000 × 0,001 € = 10 €

No compensa para chatbots en vivo, pero para pipelines de datos, ETL con IA, análisis periódicos, el 50% sale gratis.

Cómo implementarlo sin montar infraestructura

Tres caminos según nivel técnico y requerimientos:

Camino 1: código propio + providers directos (máximo control)

Para quien tiene equipo backend y quiere todo en su código:

1. Implementa classify como regla + clasificador ligero.

2. Usa el SDK oficial de cada proveedor y haz switch por modelo.

3. Añade retries con exponential backoff en tu HTTP client.

4. Usa prompt caching explícito donde esté disponible.

5. Para workloads nocturnos, usa Batch APIs.

Pro: cero dependencia externa, máximo control, sin markup.
Contra: mantener la integración (autenticación, rate limits, errores, observabilidad) es trabajo continuo.

Camino 2: gateway open-source (control + menos código)

Desplegar LiteLLM en un Docker:

docker run -d -p 4000:4000 \
  -e OPENAI_API_KEY=... \
  -e ANTHROPIC_API_KEY=... \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml

Tu aplicación habla con http://litellm:4000/v1 como si fuera OpenAI. LiteLLM reenruta internamente al proveedor que corresponda según tu config.

Pro: open-source, MIT. Routing, caching, retries, observabilidad declarativos.
Contra: debes desplegar y mantener Docker + base de datos.

Camino 3: gateway managed con RGPD (menos trabajo, buen cumplimiento)

Usar un gateway gestionado. Hay varios, pero para empresa europea con requisitos de RGPD lo que importa es dónde corre la inferencia y si hay Zero Data Retention real.

Levante Platform es una capa que hace exactamente esto bajo infraestructura europea (Tensorix en Frankfurt) con Zero Data Retention activado por defecto. Un solo endpoint, múltiples modelos, facturación por créditos, sin markup por token frente a los proveedores.

Pro: cero infraestructura, cumplimiento RGPD sin romper nada, una API key para todo.
Contra: managed service (dependencia del provider).

Cuánto se ahorra en la práctica

Compilación de casos reales observados en equipos que implementaron estos patrones:

El ahorro promedio está en el rango 60-80% cuando se aplican los cuatro patrones juntos. Solo con enrutamiento básico (patrón 1), el ahorro ya está entre 40% y 60%.

Errores comunes al implementar enrutamiento

Tras ver unos cuantos equipos hacer esto mal, los errores recurrentes son:

1. Clasificar con el modelo caro: mandar cada petición a Opus para que decida si usar Haiku es absurdo. El clasificador debe ser el modelo más barato posible.

2. No medir calidad: bajar a Haiku sin medir el impacto en satisfacción del usuario es jugar a la lotería. Monta un eval set y compara respuestas antes de desplegar.

3. Ignorar cold start del caching: el primer write cuesta 1,25-2× el input base. Si cacheas algo que solo usas una vez, pagas más.

4. Fallbacks mal configurados: si todos los proveedores tienen el mismo timeout de 10 s, cuando uno cae, el reintento también tarda 10 s. Escalona.

5. Olvidar el batch: equipos que tienen un 30% del tráfico en procesos nocturnos pero lo mandan a la API síncrona regular, pagando el doble sin motivo.

Cuándo NO merece la pena

Enrutamiento inteligente añade complejidad. Si tu factura de APIs es menor a 300 €/mes, probablemente el ROI no compensa el tiempo de implementación. Primero valida producto, después optimiza.

También puede no compensar si:

• Todas tus peticiones son realmente difíciles y necesitan modelo premium (un generador de código complejo).

• Tu latencia es crítica (<500ms end-to-end) y el router añade 100-200ms.

• Tu caso de uso depende de features únicas de un solo modelo (vision specific, audio, etc.).

En esos escenarios, focaliza en cachear y batch si aplica; el routing puro añade poco.

Conclusión

Reducir la factura de APIs de IA no es magia: es arquitectura. Los cuatro patrones — enrutamiento, caching, fallbacks, batch — están documentados, tienen herramientas maduras, y en conjunto bajan costes entre un 60% y un 80% sin tocar la UX ni la calidad percibida.

Si tu equipo está pasando de "jugar con IA" a "la IA es parte del producto", implementar estos patrones hoy te ahorra escalar problemas mañana. Si prefieres no montar nada y que otro lo haga, Levante Platform es exactamente esa capa — con RGPD y sin markup.

Para profundizar en la parte estratégica:

• BYOK y multi-proveedor: guía completa — pillar con el panorama completo.

• OpenAI vs Anthropic vs Google desde la misma app — cuándo usar cada modelo.

• ¿Qué es BYOK? — el concepto base.

Fuentes verificadas

• Prompt caching Anthropic (90% descuento cache hits): platform.claude.com/docs/en/build-with-claude/prompt-caching.

• Comparativa LiteLLM / Portkey / OpenRouter: pkgpulse.com/blog/portkey-vs-litellm-vs-openrouter-llm-gateway-2026.

• Precios API confirmados en dashboards oficiales de OpenAI, Anthropic y Google (abril 2026).

• Datos verificados el 23 de abril de 2026.