Wäg y LiteLLM: misma API, capa distinta

No es un competidor en la misma capa

La misma superficie de API compatible con OpenAI. La misma configuración, importable.

Gratis aquí. Enterprise allí.

Ambos proyectos son de código abierto con un nivel comercial. La pregunta nunca fue si existe una edición de pago, sino dónde traza cada uno la línea. La documentación Enterprise de LiteLLM enumera lo que activa su clave de licencia, y la mayor parte de esa lista en Wäg es Apache-2.0. En multiinquilino la diferencia es estructural: en su esquema de base de datos publicado, una organización lleva un presupuesto, acumulados de gasto y una lista de miembros, y un equipo apunta a ella mediante una clave externa opcional, lo que la convierte en un nivel de agrupación por encima de los equipos. En Wäg una organización es una frontera de autorización que se comprueba en cada petición. Donde nosotros ponemos la misma capacidad tras una licencia, la tabla lo dice.

Seamos justos: su nivel Enterprise también incluye listas de IP permitidas y un informe SOC 2 Type II. Hoy no tenemos ninguno de los dos.

La columna de LiteLLM procede de su propia documentación Enterprise, que indica que una clave de licencia activa las funciones allí listadas. No figura significa que una capacidad no se nombra en esa página, lo que no equivale a que sea imposible. La columna de Wäg es la división de licencia que aplica el gateway: una capacidad Enterprise es un módulo que una licencia firmada tiene que nombrar. Las filas de agentes marcadas como No figura son un No figura de otra naturaleza: su gateway de agentes no es en absoluto una función Enterprise, así que esas capacidades faltan en su producto en lugar de estar incluidas en el precio de su licencia.

Ambos ofrecen una pasarela de agentes. Solo uno gobierna al agente.

LiteLLM añadió una pasarela de agentes A2A, y hace bien lo evidente: registrar agentes, controlar qué equipos y claves pueden alcanzarlos, imputar el coste. Dos filas son paridad real. Las demás son donde los dos productos dejan de ser lo mismo.

La columna de LiteLLM recoge lo que muestran su propia documentación y su repositorio público. No documentado significa que la capacidad no se describe allí, lo que no equivale a que sea imposible. Tres filas merecen el detalle. Su parada de emergencia dispara un webhook al runtime del agente y deja, en sus propias palabras, al agente registrado y habilitado del lado de LiteLLM; la nuestra rechaza al agente en la pasarela, en cada réplica y región, y corta un flujo que ya está en curso. Su require_approval es el campo de OpenAI: con cualquier valor distinto de never, la llamada vuelve al cliente para que la ejecute — no se retiene nada, no se nombra a nadie, no se registra nada. Y para los pagos de agentes, una búsqueda de código en su repositorio de x402 y AP2 no devuelve absolutamente nada. En las API de terceros la diferencia no es el reenvío. Sus endpoints de pass-through enrutan a cualquier API externa con una credencial puesta en la configuración, y los permisos por clave y equipo son una función Enterprise. Lo que falta es la decisión: el destino es una ruta estática y no algo que un agente concreto pueda o no alcanzar, ninguna regla lee los argumentos de la llamada, ninguna aprobación puede retenerla, no lleva etiqueta de flujo y no cuenta en una ejecución.

Cómo funciona la gobernanza de agentes en Wäg

Casos en los que LiteLLM es la respuesta correcta

Sinceramente. Si reconoce aquí su situación, adoptar un control plane le añade una superficie operativa que todavía no necesita.

• Un solo equipo, uno o unos pocos servicios, y quiere multiproveedor hoy mismo.
• Usa import litellm dentro del código de la aplicación por su enrutamiento en proceso y sus callbacks, y valora eso directamente.
• Tiene callbacks de Python propios en el ciclo de vida de la petición cuya reimplementación supondría un trabajo real.
• Su lista de proveedores incluye alguno de nicho que Wäg todavía no cubre.
• Sus requisitos de gobierno quedan realmente satisfechos con presupuestos por clave.

Los síntomas, no la lista de funcionalidades

• Los presupuestos deben reflejar su organigrama. Los límites por clave no pueden expresar «este equipo dispone de 4.000 €, ningún usuario individual más de 500 € y los experimentos de marketing no pueden consumir la capacidad de ingeniería».
• La política tiene que aplicarse a aplicaciones que nunca se adhirieron. Una regla que solo puede aplicar allí donde alguien se acordó de añadirla no es un control.
• Los agentes han ampliado mucho la superficie. Un turno de usuario se convierte en N llamadas a modelos y herramientas contra servidores MCP remotos. La autenticación por servidor, las ACL de herramientas y la auditoría por salto dejan de ser un lujo.
• Alguien preguntó cuánto costó la IA, por equipo, el trimestre pasado. Y responder exigió un proyecto de datos en lugar de un cuadro de mando.
• El cumplimiento necesita registros, no intenciones. Desde el 2 de agosto de 2026, las competencias sancionadoras sobre la IA de uso general y las obligaciones de transparencia del artículo 50 del Reglamento Europeo de IA conllevan exposición a sanciones. El registro y la trazabilidad tienen que poder demostrarse.
• El gateway pasó a ser estructural. Cuando todas las rutas de producto pasan por él, un proceso de Python con un intérprete y un árbol de dependencias resuelto en el despliegue plantea una conversación de riesgo distinta de la que planteaba con diez peticiones por minuto.

Lo que no cambia en absoluto

Compromisos de diseño, no un recuento de funcionalidades

Las tablas de funcionalidades quedan obsoletas en un trimestre. Estas son decisiones estructurales que no cambian con una versión.

Si LiteLLM está haciendo su trabajo, consérvelo. Si lo que de verdad está tensionado es el gobierno y no el enrutamiento, se trata de otra capa — y es aquella para la que se ha construido Wäg.