La forma más rápida de construir un producto de AI Ops que pierda dinero con cada cliente es elegir tu modelo más inteligente y enrutar todo a través de él. Se siente responsable: razonamiento de nivel Opus en cada alerta, sin concesiones, calidad máxima. Después llega la factura y descubres que acabas de pagar precios de modelo frontera para clasificar un reinicio rutinario de pod como “probablemente esté bien”.

Este es el error que casi todos cometen primero, y es justo el que el motor Autopilot de KubeBolt fue diseñado para evitar. La tesis es simple: la mayoría de los incidentes no necesitan tu mejor modelo, y una buena parte no necesita modelo alguno. El truco está en saber cuál es cuál antes de gastar los tokens.

El enfoque naif y por qué quema dinero

Los clusters de Kubernetes son mangueras de eventos. Un solo cluster bajo estrés moderado emite cientos de eventos Warning por hora: BackOff, FailedScheduling, OOMKilled, fallos transitorios de probe, el pod que reinicia una vez y se recupera. Si tu arquitectura es “cada evento va a un modelo grande”, estás pagando precios frontera por un flujo que es, en su abrumadora mayoría, ruido y patrones bien conocidos.

La estructura de costo de los modelos de razonamiento frontera vuelve esto brutal. Los números exactos se mueven cada trimestre y varían por proveedor, así que trata cualquier cifra dura como ilustrativa. Pero la forma es estable y es lo que importa: una llamada de nivel Opus puede costar del orden de 100x una llamada de nivel Haiku para el mismo volumen de tokens, y una investigación profunda que quema decenas de miles de tokens en tool use multi-turno cuesta bastante más todavía. Corre eso en cada evento y tu costo por incidente queda dominado por los incidentes que nunca necesitaron la inteligencia en primer lugar.

Peor aún: es más lento y no más preciso. Un modelo frontera al que le preguntas “¿este reinicio de pod es ruido?” te da la misma respuesta que uno barato, solo que más tarde y más caro. El desperdicio no es un error de redondeo: es la factura entera.

Cómo enruta KubeBolt entre sus capas

Autopilot es un motor de seis capas. Solo tres de ellas tocan un LLM, y el trabajo de cada capa es resolver el incidente lo más barato posible o pasarlo hacia arriba con una razón clara. El LLM propone; un executor determinístico actúa.

Capa	Trabajo	Nivel de modelo	Costo relativo	Cuándo se usa
L1 Detectores	Matchear patrones conocidos y remediar	ninguno (determinístico)	casi gratis	En cada incidente, primero
L2 Router	Triage: ruido vs investigar vs crítico	nivel Haiku	base (1x)	Lo que L1 no puede matchear
L3 Investigator	Root cause con tool use multi-turno	nivel Sonnet	~pocas veces la base	Incidentes que no son ruido
L4 Planner	Escribir el plan de remediación	Sonnet, Opus para casos duros	hasta ~100x la base	Solo cuando hace falta un plan
L5 Executor	Aplicar el plan bajo guardarraíles	ninguno (determinístico)	casi gratis	En cada plan aprobado
L6 Postmortem	Escribir el reporte del incidente	nivel Opus	alto, pero asíncrono	Tras resolver, fuera del camino crítico

Las cifras de costo relativo son ilustrativas y por token; los precios reales cambian con cada actualización de proveedor. Lo que se mantiene estable son los multiplicadores entre niveles, y son toda la razón por la que existe el enrutamiento.

La capa 1, los Detectores, es donde viven de verdad los ahorros, y no usa LLM en absoluto. Son reglas determinísticas, portadas del mismo motor de Insights que viene en el agente open source. OOMKilled después de un deploy, un image pull fallando por un tag inexistente, un PodDisruptionBudget bloqueando un drain: son patrones que ya sabemos reconocer y remediar en Go puro. Una porción bien conocida de los incidentes reales de Kubernetes cae en formas ya vistas, y la capa 1 los resuelve en menos de 50 milisegundos, con un score de confianza y cero gasto de tokens. La capa más importante de un sistema construido sobre LLMs es la que no llama a ninguno.

Solo cuando la capa 1 no puede matchear con confianza el evento escala, y aun así sube los niveles de a un peldaño por vez.

La capa 2, el Router, es triage de nivel Haiku. Su único trabajo es responder una pregunta en menos de 200 tokens de output: ¿esto es noise, amerita investigate, o es critical? El ruido se marca y se descarta. Este es a propósito el modelo más barato posible haciendo la tarea más barata posible, porque el triage es un filtro, no un análisis. A grosso modo 100x menos que una llamada Opus, puedes darte el lujo de correrlo sobre todo lo que la capa 1 dejó pasar y aun así casi no mover la aguja.

La capa 3, el Investigator, es de nivel Sonnet y aquí ocurre el trabajo real. Corre tool use multi-turno (las mismas diecisiete tools que expone el Copilot) en modo autónomo: traer logs de pods, describir el deployment, consultar una métrica, correlacionar eventos recientes. Itera hasta llegar a una hipótesis con confianza por encima de 0.7, o se rinde tras un número acotado de turnos y marca el incidente para un humano. Sonnet es el nivel correcto aquí porque investigar necesita razonamiento genuino y orquestación de tools, pero no la frontera absoluta. La mayoría de los root causes no la requieren.

La capa 4, el Planner, es el único lugar donde un modelo de nivel Opus se gana el sueldo, y aun así solo a veces. Si la investigación es de baja complejidad y de un solo paso, Sonnet escribe el plan. Opus queda reservado para los casos genuinamente difíciles: remediaciones multi-step, trade-offs de riesgo sofisticados, planes donde equivocar el orden empeora las cosas. Esta es la inversión que la mayoría se pierde. Opus no es el default desde el que optimizas hacia abajo: es la excepción a la que escalas hacia arriba.

La capa 5, el Executor, vuelve a ser determinística. Toma el plan y lo aplica acción por acción contra una whitelist cerrada de unas veinticinco operaciones, bajo RBAC, con rollback automático si la verificación falla. Ningún LLM decide qué se corre en tu cluster. El modelo escribe una propuesta; código con guardarraíles la ejecuta. Ese límite es una propiedad de seguridad, y también es una propiedad de costo: ejecutar no gasta tokens.

La capa 6, el Postmortem, corre Opus de forma asíncrona tras la resolución. Es el único lugar donde gastamos contentos en calidad, porque está fuera del camino crítico, no bloquea nada, y un buen reporte lo vale.

Lógica de enrutamiento: qué decide la escalada

La escalada no va por intuición. Cada frontera tiene una señal explícita:

Capa 1 a Capa 2: los detectores determinísticos no matchean, o matchean con confianza igual o menor a 0.9. Un match de alta confianza corta las capas LLM por completo; un match débil igual escala, pero se pasa hacia abajo como pista para el investigator.
Capa 2 a Capa 3: el Router clasifica el evento como investigate o critical. Un veredicto de noise termina el incidente. Este es el filtro de mayor apalancamiento del sistema, porque es la compuerta barata que evita que el ruido llegue siquiera a un modelo de nivel medio.
Capa 3 a Capa 4: el Investigator llega a una hipótesis con confianza suficiente para actuar. Si no supera la barra de confianza dentro de su presupuesto de turnos, escala a un humano en lugar de adivinar.
Elección de modelo en Capa 4: Opus solo cuando la investigación se marca como de alta complejidad o el plan es multi-step. En otro caso lo escribe Sonnet.

Encima va el backpressure, que en realidad es control de costo disfrazado de resiliencia. Un semáforo por org limita las investigaciones concurrentes, así una mala tarde no se abre en abanico hacia cientos de sesiones Sonnet en paralelo. Y cuando un cluster emite más de unos 50 eventos por minuto, Autopilot deja de investigar eventos individuales por completo: eso no son cincuenta incidentes, es un outage. Los colapsa en un único incidente de “cluster outage” y llama directo a un humano. Investigar cada evento por separado durante un outage real sería tan inútil como ruinosamente caro, así que no lo hacemos.

Los números, con honestidad

Aquí viene la parte donde los vendedores de AI Ops suelen citar una cifra en dólares sospechosamente precisa. No lo haremos, porque los precios por llamada de los modelos cambian con cada actualización de proveedor y cualquier número que escriba aquí quedará viejo el trimestre que viene. Lo durable es la proporción y la arquitectura que la explota.

Los multiplicadores son el punto. Cuando una llamada de nivel Opus cuesta del orden de 100x una de nivel Haiku, todo el juego económico consiste en mantener el trabajo en el nivel más bajo que de verdad pueda resolverlo. Un sistema que resuelve una buena parte de los incidentes en la capa 1 por cero tokens, filtra la mayor parte del resto por una compuerta de nivel Haiku, atiende a los sobrevivientes con Sonnet, y reserva Opus para una tajada fina de planes genuinamente difíciles tiene una curva de costo radicalmente distinta a “Opus para todo”. No un poco más barato: otro orden de magnitud.

En concreto, eso es lo que le permite a KubeBolt Autopilot resolver incidentes reales de punta a punta en menos de 90 segundos, por menos de $1 cada uno incluyendo el gasto de LLM. La versión de un solo modelo grande del mismo producto no solo cuesta más por incidente: cuesta más en los incidentes que menos ayuda necesitaban, que es exactamente al revés. Enruta con inteligencia y los incidentes baratos y comunes casi no cuestan nada, así tu promedio se mantiene bajo incluso cuando el ocasional caso peludo sube toda la pila hasta Opus.

Resiliencia: failover multi-proveedor

Enrutar entre niveles de modelo resuelve el costo. Enrutar entre proveedores de modelo resuelve la disponibilidad, y en producción necesitas ambas.

Cada llamada LLM en Autopilot pasa por un AI Gateway interno que hace failover entre tres proveedores en orden:

1. Anthropic API      (primario)
2. Google Vertex AI   (failover #1)
3. AWS Bedrock        (failover #2)

Un circuit breaker marca un proveedor como caído por 60 segundos tras tres fallos consecutivos, así un tropezón regional en un proveedor no frena tu pipeline de incidentes: el gateway pasa al siguiente y sigue. Como las mismas familias de modelos Claude (Haiku, Sonnet, Opus) están disponibles en las tres superficies, el failover no cambia la lógica de enrutamiento ni la calidad de la respuesta. El nivel se mantiene: solo cambia el camino que toma. Esta es la diferencia entre “nuestro AI Ops se rompió porque Anthropic tuvo cinco minutos malos” y una nota al pie en un log.

El trade-off honesto

Nada de esto es gratis, y sería deshonesto fingir lo contrario. Una arquitectura de un solo modelo es genuinamente más simple. Un cliente, un estilo de prompt, un conjunto de modos de fallo, una sola cosa sobre la que razonar. Lo que describimos es una capa de enrutamiento con seis etapas, prompts por nivel, umbrales de confianza que hay que calibrar, un semáforo, un detector de outage, un circuit breaker y un gateway de tres proveedores. Eso es superficie operativa real. Es más código que testear, más bordes donde equivocarse, más dashboards que mirar.

Esa complejidad se siente más cuando el enrutamiento falla. Un Router demasiado agresivo marca un incidente real como ruido y se te escapa algo; demasiado tímido y escala ruido a investigaciones pagas, erosionando en silencio el ahorro que todo el diseño existe para capturar. Los umbrales de confianza en cada frontera son perillas, y las perillas derivan. Ajustarlos bien es trabajo continuo, no un setup de una sola vez, y es del tipo que solo aparece en métricas agregadas y no en ningún incidente individual.

Así que el encuadre honesto es un canje, no un almuerzo gratis: asumes complejidad de ingeniería significativa a cambio de una reducción de costo de un orden de magnitud y resiliencia a nivel de proveedor. Para una herramienta que corres de vez en cuando, ese canje no vale la pena: corre un buen modelo y sigue. Para un sistema autónomo procesando cada evento en producción las 24 horas, el costo de no enrutar se acumula en cada incidente, y la complejidad se paga sola muchas veces. Ese es el régimen en el que opera KubeBolt, y por eso existe la capa de enrutamiento.

Tres LLMs son de verdad mejor que uno. Pero la parte más afilada del diseño es la capa que resuelve la mayoría de los incidentes sin usar ningún LLM. Si quieres el panorama completo, la arquitectura está documentada en los docs, y el agente open source que alimenta los detectores de la capa 1 está en GitHub, Apache 2.0, legible de punta a punta.