busbar

Busbar funciona como una frontera de aplicación operada por el cliente para sistemas de IA, en lugar de un proxy inverso genérico. Se sitúa en la ruta de solicitud entre aplicaciones y agentes de IA, y destinos posteriores como proveedores de LLM, herramientas MCP y agentes A2A, lo que permite a los operadores verificar, gobernar, enrutar y registrar llamadas a modelos, uso de herramientas y delegación de agentes antes de que las solicitudes lleguen a destinos aprobados. El proyecto es totalmente autoalojado, sin servicio gestionado alojado, sin registro obligatorio y sin comportamiento de llamada saliente a casa; todas las credenciales de proveedores permanecen dentro de la propia infraestructura del operador en la frontera de aplicación. Proporciona soporte de primera clase para seis protocolos de comunicación de LLM tanto en ingreso como en egreso: OpenAI, OpenAI Responses, Anthropic, Gemini, Cohere y Bedrock Converse, cubriendo los 36 pares posibles de protocolos de ingreso a ascendente. Las rutas del mismo protocolo reenvían directamente los bytes originales de la solicitud, ofreciendo paridad byte por byte con llamadas directas al proveedor, mientras que las rutas entre protocolos traducen los campos de la solicitud para que coincidan con el formato nativo del proveedor de destino. La integración del cliente solo requiere cambiar la URL base y la clave de API para apuntar a una instancia de Busbar, sin cambios en los flujos de trabajo existentes con SDK nativos. El despliegue está diseñado para una sobrecarga operativa mínima: Busbar se distribuye como un único binario estático de Rust que no requiere intérprete, base de datos ni sidecar por separado, o como una pequeña imagen de contenedor comprimida. La configuración se define en un único archivo YAML, con un comando integrado de validación de configuración que se ejecuta sin acceso a la red ni servidor en funcionamiento, adecuado para su inclusión en canalizaciones de CI. Se proporcionan gráficos Helm oficiales para el despliegue en Kubernetes, con valores predeterminados de seguridad reforzados, incluida la ejecución sin root, sistema de archivos raíz de solo lectura y eliminación de capacidades de Linux innecesarias. Las capacidades operativas principales incluyen grupos de modelos ponderados con límites de concurrencia por carril, disyuntores con atribución de fallos y conmutación por error en vuelo que cambia de proveedor antes de que el primer byte de respuesta llegue al cliente, incluso para solicitudes en streaming. Los controles de gobernanza integrados incluyen claves de API virtuales, presupuestos y seguimiento de gasto a nivel de grupo, soporte nativo de TLS y mTLS, telemetría Prometheus y OTLP, y webhooks de auditoría por solicitud. El modelo más amplio de frontera de ejecución del proyecto extiende este mismo patrón de aplicación a la gobernanza de herramientas MCP (concesiones de llamadores, esquemas aprobados, aplicación de presupuestos, cuarentena por deriva) y a la confianza de agentes A2A (verificación, fijación, control de egreso, credenciales vinculadas al destino). El proyecto publica mediciones de referencia para su propia implementación, incluida una latencia añadida p50 de 73 microsegundos, 67.837 solicitudes por segundo sostenidas con cero fallos, 7,3 MiB de memoria residente en reposo y una imagen de contenedor comprimida de 5,74 MiB, con comparaciones públicas frente a otras herramientas comunes de puerta de enlace de IA y de API general. El proyecto se publica bajo la licencia Apache 2.0, con un contrato estable según SemVer para su superficie HTTP del plano de datos y contratos de protocolos de comunicación compatibles en las versiones principales.