AI FinOps · Mayo 2026

Anatomía de la factura de Claude que rompió el presupuesto de Uber

Uber agotó su presupuesto 2026 de IA en cuatro meses. No es un accidente raro: es la consecuencia natural de combinar pricing por token con agentes que paralelizan llamadas. Esta es la autopsia técnica del overrun y los cuatro pilares del AI FinOps que lo hubieran evitado.

El CTO de Uber regresa al pizarrón

El 16 de abril de 2026, The Information publicó una entrevista breve pero contundente con Praveen Neppalli Naga, CTO de Uber. La frase que se viralizó en LinkedIn al día siguiente:

“I'm back to the drawing board because the budget I thought I would need is blown away already.”

El contexto: el presupuesto anual de IA que Uber proyectó para 2026 se agotó en aproximadamente cuatro meses. La causa inmediata no fue un proyecto mal planeado. Fue una adopción exitosa que escaló más rápido de lo que el modelo financiero anticipaba: el porcentaje de ingenieros usando Claude Code pasó del 32% en diciembre de 2025 al 84% en abril de 2026, sobre una base de ~5,000 ingenieros. Para entonces, alrededor del 11% de los cambios productivos en el backend ya eran código escrito por IA. Los costos de IA en Uber alcanzaron aproximadamente 6 veces los niveles de 2024.

Esto le pasó a una empresa pública (NYSE: UBER), con un departamento de FinOps maduro, $3.4 mil millones de R&D en 2025 y acceso directo al equipo enterprise de Anthropic. Si les pasó a ellos, le puede pasar a cualquier empresa LATAM que esté escalando agentes sin haber instrumentado el stack de governance.

Este post no es una pieza de marketing del miedo. Es la autopsia técnica de cómo se rompe una factura de Claude — con números verificados de la página oficial de Anthropic al 17 de mayo de 2026 — y la receta concreta de los cuatro pilares de AI FinOps que evitan repetirla.

Por qué tu intuición de SaaS tradicional falla con LLMs

Un CFO que ha aprobado contratos de Salesforce, Snowflake o Workday durante una década tiene un modelo mental claro: pricing per-seat o por capacidad reservada, con consumo predecible y crecimiento lineal. Con LLMs ese modelo no aplica. Tres razones técnicas:

1. El pricing es por token, no por usuario. Un “usuario” activo no es la unidad económica. La unidad económica es cuántos tokens procesa por consulta y cuántas consultas dispara al día. Un ingeniero corriendo Claude Code con agentes puede consumir entre $500 y $2,000 USD al mes en tokens según los datos reportados por Uber. Diez ingenieros equivalentes a un asiento típico de Microsoft 365.

2. Los agentes paralelizan llamadas de forma no lineal.Un agente que “piensa” ejecuta múltiples llamadas al modelo por tarea: planificación, ejecución, verificación, retry en caso de error. Una consulta humana puede traducirse en 20 o 50 llamadas internas. Si tu observabilidad cuenta requests al endpoint del agente y no llamadas al modelo subyacente, tu dashboard miente.

3. No hay rate limit natural del usuario. Un humano hace una consulta cada 30 segundos como máximo. Un agente puede disparar 50 llamadas por minuto. El caso público más citado: un desarrollador independiente que dejó corriendo una sesión de Replit AI Agent sin supervisión generó una factura de $607 USD en un solo periodo de facturación — porque el agente iteró, debuggeó y reconstruyó por horas sin que nadie cortara el bucle. Un solo agente sin tope técnico puede generar más gasto en una noche que cien usuarios humanos en un mes.

El problema entonces no es que “Claude es caro” — los precios de Anthropic, como veremos en la tabla más abajo, son competitivos. El problema es que la arquitectura por defecto de la mayoría de los pilotos no incluye los controles que convierten un costo variable impredecible en un costo variable acotado.

La autopsia: seis formas en que una factura de Claude se sale de control

Cualquier overrun de LLM en producción cabe en una o más de estas seis categorías. La buena noticia: cada una tiene un control técnico conocido.

1. Loops de agente sin tope (runaway agents)

El patrón Replit. Un agente entra en un bucle de planificación-ejecución-verificación sin un budget cap explícito en el orchestrator. La primera línea de defensa es un límite duro de tokens por sesión (no por request) implementado en la capa de proxy. Sin esto, el peor escenario de tu factura mensual es ilimitado.

2. Modelo sobredimensionado para la tarea

Usar Opus 4.7 ($5 input / $25 output por millón de tokens) para una tarea que Haiku 4.5 ($1 / $5) resuelve igual. Una clasificación de tickets de soporte, una extracción estructurada de un PDF, una traducción rutinaria — todas son trabajo de Haiku. Equipos que hacen routing manual al modelo “más capaz” por costumbre pagan 5x el costo de input y 5x el de output sin diferencia de calidad medible en sus benchmarks reales.

3. Sin prompt caching

Anthropic permite cachear el prefijo de un prompt — el system prompt, las herramientas declaradas, el contexto fijo. Una lectura cacheada cuesta el 10% del precio de input regular: descuento del 90%. Si tu system prompt incluye 50,000 tokens de documentación interna o regulación CNBV y no estás usando cache_control, estás pagando esos 50,000 tokens en cada consulta cuando podrías pagarlos una vez por hora.

4. Sin Batch API para cargas asíncronas

El Batch API de Anthropic ofrece 50% de descuento tanto en input como en output, a cambio de tolerar ventanas de procesamiento de hasta 24 horas. Para análisis nocturnos, batch scoring, generación masiva de embeddings o procesamiento documental — todo lo que no requiere respuesta en tiempo real — no usar Batch API es regalar la mitad del costo. Se apila además con prompt caching, así que el ahorro compuesto puede llegar al 95%.

5. Sin observabilidad por usuario

Si tu dashboard de costos muestra solo “tokens por día”, no puedes detectar al power user que consume el 40% del presupuesto, ni al script externo que está scrapeando tu API. La capacidad mínima para gobierno de costos es cost per user y cost per workflow con atribución desde el primer día.

6. Tokenizer drift (la trampa de Opus 4.7)

Esto sorprende a equipos que migran versiones. Anthropic lo declara explícitamente en su página de pricing: “Opus 4.7 uses a new tokenizer compared to previous models... This new tokenizer may use up to 35% more tokens for the same fixed text.” Traducción: para el mismo texto, Opus 4.7 puede contar hasta un 35% más tokens que Opus 4.6 o 4.5. Migrar a 4.7 sin re-baseline-ar tu modelo de costos significa que tu próxima factura puede ser 35% más alta sin que aumente tu volumen.

Los precios reales de Claude en 2026 — la tabla que tu CFO necesita ver

Todos los números a continuación están tomados directamente de la página oficial de pricing de Anthropic (platform.claude.com/docs/en/about-claude/pricing) y verificados al 17 de mayo de 2026. Los precios son por millón de tokens en USD.

El Batch API aplica un 50% adicional sobre input y output. La página oficial de Anthropic incluye un ejemplo trabajado que vale citar literalmente: procesar 10,000 tickets de soporte con un promedio de ~3,700 tokens por conversación en Haiku 4.5 cuesta aproximadamente $37 USD totales. Treinta y siete dólares.

La distancia entre $37 y $3 millones no es el modelo. Es la arquitectura. Si tu factura de Claude es de varios millones al mes y no estás procesando significativamente más que ese ratio de tokens-por-consulta, hay un problema de architecture, no de pricing.

Los cuatro pilares del AI FinOps

Estos cuatro controles, implementados antes de que el volumen escale, son la diferencia entre “crece nuestra adopción de IA” y “crece nuestra adopción de IA y nuestro CFO entiende exactamente por qué”.

Pilar 1: Rate limiting y cuotas por usuario

El primer control. No vive en tu aplicación; vive en una capa de proxy entre tu aplicación y Anthropic. Los gateways genéricos (AWS API Gateway, Kong, Apigee) limitan requests por segundo pero son ciegos al costo de cada request en tokens. Para LLMs necesitas un gateway que entienda economía de tokens. Las opciones probadas:

• LiteLLM (open source, SOC-2 Type 2): virtual keys con presupuesto por equipo, tracking de gasto en Postgres, retorno de HTTP 429 cuando una key agota su budget. Es la opción más adoptada para deployments self-hosted.
• Portkey: gateway comercial con caching semántico, guardrails y visibilidad de costo por request, todo cross-provider (Anthropic, OpenAI, Bedrock).
• Cloudflare AI Gateway: hosted, integración trivial si ya estás en Cloudflare.
• Kong AI Gateway: extensión LLM-aware sobre Kong, útil si ya tienes Kong en producción.

La distinción crítica: soft limit dispara una alerta cuando se cruza un umbral (típicamente 80% del budget mensual) pero deja pasar el request; hard limit rechaza el request con 429 cuando se agota el budget. Toda capa de governance LLM necesita ambos. El soft limit te da tiempo de actuar; el hard limit te evita la sorpresa del lunes.

Pilar 2: Caching

Hay dos tipos de caching y los necesitas a ambos por razones distintas.

Prompt caching nativo de Anthropic. Marcas un prefijo del prompt con cache_control; Anthropic hashea el prefijo y, en consultas subsecuentes con el mismo prefijo, te cobra ese tramo cacheado al 10% del costo de input regular. Detalles que importan:

• Tamaño mínimo cacheable: 4,096 tokens para Opus 4.7/4.6/4.5 y Haiku 4.5; 1,024 tokens para Sonnet 4.6/4.5.
• TTL: 5 minutos (write a 1.25x input) o 1 hora (write a 2x input).
• Punto de equilibrio: un solo hit ya paga el write de 5 minutos; dos hits pagan el write de 1 hora.
• Anthropic publica el ejemplo: un documento cacheado de 100K tokens en Opus 4.7 cuesta $0.625 escribir y $0.05 por cada lectura subsecuente — reducción del 90% del costo de input para contenido reutilizado.

Caching semántico (third-party). A diferencia del prompt caching nativo — que requiere prefijo idéntico — el caching semántico compara similitud. Embebes la consulta entrante, haces vector search contra un cache de pares (consulta → respuesta) previos, y si la similitud excede un umbral (típicamente 0.85–0.95) sirves la respuesta cacheada sin llamar al modelo. Útil para FAQs internas, soporte de primer nivel, consultas regulatorias frecuentes.

Implementaciones probadas: GPTCache (open source, integra con Pinecone, Weaviate, pgvector, Qdrant, Redis Vector), Portkey con su capa semántica, o un build propio sobre tu vector DB existente. El paper de GPT Semantic Cache reporta reducciones de hasta 68.8% en llamadas a la API en experimentos controlados.

Pilar 3: Model routing

El error más caro y más fácil de corregir. Cada consulta debe ir al modelo más pequeño que la resuelva con calidad aceptable. Anthropic mismo lo dice en su guía de cost optimization: “Haiku para tareas simples, Sonnet para la mayoría de cargas productivas, Opus para el razonamiento más complejo.”

Heurística práctica para empezar:

• Haiku 4.5 ($1/$5 por MTok, ~96 tokens/segundo): clasificación, extracción estructurada, triage de tickets, sub-agentes worker que solo siguen instrucciones explícitas. SWE-Bench Verified 73%.
• Sonnet 4.6 ($3/$15): coding asistido, agentes conversacionales de cara al cliente, razonamiento general. Es el caballo de batalla de la mayoría de los deployments productivos.
• Opus 4.7 ($5/$25): coding agentic complejo (SWE-Bench Verified 87.6%), planning multi-step, casos donde Sonnet falla consistentemente. Ojo con el tokenizer nuevo que cuenta hasta 35% más.

Para automatizar la decisión, hay frameworks publicados. RouteLLM (Ong et al., 2024, arXiv 2406.18665, código en lm-sys/RouteLLM) demostró que con un router entrenado se puede mantener el 95% del performance de GPT-4 usando solo el 14% de las llamadas a GPT-4, redirigiendo el resto a modelos baratos — reducción superior al 85% en costo en algunos benchmarks. La misma lógica aplica a Haiku ↔ Sonnet ↔ Opus.

Opciones comerciales si no quieres construir el router: Martian, NotDiamond, OpenRouter, el routing nativo de Portkey o el de LiteLLM.

Pilar 4: Observabilidad

Sin observabilidad granular, los tres pilares anteriores son ciegos. No sabes si tu caching está pegando, no sabes si tu router está enviando 30% de tráfico a Opus que Haiku resolvería, no sabes qué usuario consume más. Las herramientas establecidas:

• Helicone: observabilidad LLM por proxy (cambias el base URL y listo). Tracking de costo automático, cache hit rate, métricas por usuario. Self-hosteable.
• Langfuse: open source, basado en SDK. Granularidad fina de tokens / latencia / cache, atribución por usuario, self-hosteable.
• LangSmith: la opción hosted de LangChain. Tight integration si ya usas LangChain; sin self-hosted.
• Arize Phoenix: evaluación más tracing, open source. Suele combinarse con Helicone o Langfuse.
• OpenTelemetry GenAI semantic conventions: el estándar vendor-neutral del CNCF GenAI SIG. Datadog, Google Cloud, AWS y Azure ya lo están adoptando. Sigue marcado como experimental en muchas de sus partes, pero es la apuesta futura si quieres independencia de vendor.

Las siete métricas mínimas que cualquier dashboard de AI FinOps debe mostrar:

1. Costo por consulta (cost per query)
2. Costo por usuario (cost per user) — requiere propagar user ID al proxy
3. Costo por workflow / por trace
4. Latencia P50 y P99
5. Tasa de error (4xx/5xx, errores de modelo, bloqueos de content filter)
6. Cache hit rate (tanto nativo de Anthropic como semántico si aplica)
7. Tokens por modelo (insumo del feedback loop de routing)

Arquitectura de referencia: el stack que no explota

Combinando los cuatro pilares, así se ve un deployment de Claude que no produce facturas sorpresa:

Capa 1 — Edge. Cliente → API Gateway con auth, WAF y rate limit genérico por IP. Aquí no se hace cost control de LLM; aquí se hace control de abuso.

Capa 2 — LLM Gateway. Toda llamada a Anthropic pasa por un proxy LLM-aware (LiteLLM, Portkey o Cloudflare AI Gateway). Aquí viven: virtual keys por equipo con budget, model routing (Haiku por default, escalamiento a Sonnet/Opus por reglas), retry y fallback policies, audit log de cada request.

Capa 3 — Claude API. Anthropic con prompt caching habilitado en system prompts y herramientas. Batch API para cargas asíncronas conocidas. Si compliance lo requiere, despliegue en AWS Bedrock con data residency en São Paulo o US East según el contrato.

Capa 4 — Observabilidad. Helicone o Langfuse capturando cada llamada (tokens, costo, latencia, modelo elegido, cache hit). Dashboard con las siete métricas; alertas configuradas a 80% del budget mensual por equipo. Reporte semanal automático al CFO con costo por workflow y top 10 power users.

Esta arquitectura no es exótica. Es la receta básica. Pero requiere implementarla antes de que el volumen escale, no después de la primera factura sorpresa.

El lunes en que el CFO no llama

El caso Uber es valioso porque está documentado, viene de una empresa madura y prueba que esto no es un problema de empresas chicas. Pero la historia que importa es la inversa: las empresas que escalan agentes con governance instrumentado desde el día uno no aparecen en titulares — sus CFOs tienen forecasts predecibles y sus CTOs no vuelven al pizarrón.

En Vorantis trabajamos exclusivamente con Claude y somos partner de Anthropic en LATAM. Lo que vendemos no son tokens — los tokens los compras directo a Anthropic. Lo que vendemos es la capa de governance que convierte un costo variable impredecible en un costo variable acotado. Si tu factura de Claude (o de cualquier LLM) está creciendo más rápido que tu uso, o si todavía no tienes los cuatro pilares instrumentados, una auditoría de AI FinOps de tres semanas suele identificar entre 30% y 70% de reducción a igual carga. Si lo tuyo es un piloto que no logra salir de sandbox, lo que necesitas es un Last-Mile Acceleration sprint.

Vale la pena hablar antes de que llegue la factura del lunes.

Fuentes principales: Anthropic Pricing (platform.claude.com/docs/en/about-claude/pricing), Anthropic Prompt Caching (platform.claude.com/docs/en/build-with-claude/prompt-caching), Laura Bratton — “Uber CTO Shows How Claude Code Can Blow Up AI Budgets”, The Information, 16 abril 2026 (cobertura abierta en AI Magazine), Ong et al. — RouteLLM, arXiv:2406.18665 (arxiv.org). Todos verificados al 17 de mayo de 2026.