El gasto en tokens es una línea que controlas
Gasto y límites de tasa apilados en org, equipo, usuario, aplicación, modelo y clave — con topes de reparto justo, alertas de presupuesto blando y paneles FinOps. Cada solicitud se verifica contra cada contador correspondiente, y la primera violación se rechaza.
"Gasto y límites de tasa apilados en org → equipo → usuario → app → modelo → clave — la primera violación se rechaza."
Jerarquía apilada
Gasto y límites de tasa en org → equipo → usuario → aplicación → modelo → clave. Cada solicitud se verifica contra todos los contadores correspondientes, y la primera violación la rechaza.
Topes de reparto justo
Topes por subgrupo como dólares por equipo, por usuario y por aplicación garantizan un reparto justo, de modo que un equipo nunca pueda agotar todo el pool de la organización.
Claves virtuales
Presupuestos en tokens y dólares por clave, por equipo y por usuario, límites RPM y listas de modelos permitidos — con tipos de propietario usuario o servicio para una atribución limpia.
Presupuestos blandos y alertas
Avisa en un umbral porcentual mediante un webhook antes de que los límites duros empiecen a rechazar tráfico. Ve venir el muro antes de chocar con él.
Paneles FinOps
Gasto por inquilino, modelo, proveedor y clave. Un catálogo de precios importable (paquete offline o sincronización de catálogo) y recálculo histórico del gasto.
Etiquetas de recargo
Atribuye el coste al equipo, producto o centro de costes que lo generó — el gasto en tokens se convierte en una línea de resultados que realmente puedes gestionar.
Paso a paso
- 01
Definir los contadores
Establece presupuestos en dólares y tokens y límites RPM en cualquier nivel de la jerarquía — org, equipo, usuario, aplicación, modelo o clave virtual individual.
- 02
Verificar en cada solicitud
Cada llamada se evalúa contra cada contador que se le aplica. El primer contador que se superaría rechaza la solicitud. Si Redis no está accesible, los contadores de gasto fallan en abierto salvo que esté activado el modo clúster.
- 03
Avisar, luego aplicar
Los umbrales de presupuesto blando disparan alertas por webhook a medida que el uso crece; los límites duros rechazan tráfico una vez alcanzado el tope.
- 04
Informar y recargar
El gasto se agrega en paneles por inquilino, modelo, proveedor y clave, etiquetado para el recargo y conciliable con un catálogo de precios.
budgets:
- { id: org-pool, scope: org, budget_usd: 50000, budget_period: monthly,
per_team_usd: 8000, per_application_usd: 5000 }
- { id: payments, scope: team, team_id: payments, per_user_usd: 500 }
alerts:
soft_budget_pct: 0.8 # warn before the hard limitPresupuestos y gobernanza es una de las seis superficies de control que se aplican en la misma ruta de petición, para todas las aplicaciones situadas detrás del endpoint — incluidas las que nunca se instrumentaron.
Vea cómo se combinanUn endpoint. Cada modelo. Control total.
Ejecútelo en su propia infraestructura
Todo lo necesario para operar un control plane en producción es Apache-2.0 y seguirá siéndolo: enrutamiento, alta disponibilidad, caché, failover, presupuestos, políticas, MCP, trabajos y observabilidad. Self-hosted, sin cuenta, sin phone-home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>No es un pull que funcione: las imágenes aún no son públicas. Los socios de diseño reciben los datos del registro en privado.
Despliega en 5 minutosContribuya a definirlo como design partner
Wäg todavía no se ha publicado. Trabajamos con un grupo reducido de equipos que ejecutan IA multiproveedor en producción y se toman en serio la gobernanza y la soberanía, para endurecer el control plane con cargas de trabajo reales.
- Todas las capacidades Enterprise incluidas, sin coste de licencia
- Migración acompañada: la hacemos con usted, también desde LiteLLM
- Línea directa con los ingenieros que lo construyen e influencia real sobre lo que llega después