Los equipos que corren agentes de programación chocan siempre con la misma pared. Claude Code habla la API Messages de Anthropic, Codex CLI habla la de OpenAI, y el modelo que la organización realmente quiere servir vive detrás de vLLM, NVIDIA NIM u Ollama. Reescribir el agente no es opción, así que la capa de traducción tiene que vivir en otra parte.

Switchyard es la respuesta de NVIDIA: un proxy y biblioteca en Rust para tráfico de modelos de lenguaje que enruta pedidos entre proveedores, traduce entre los formatos de OpenAI y Anthropic, registra métricas de operación y expone algoritmos de ruteo tipados y componibles. Se publicó bajo licencia Apache 2.0, con documentación en docs.nvidia.com/nemo/switchyard.

¿Se puede poner en producción?

No todavía. El binario se instala desde crates.io y el lanzador desde PyPI, y se autohospeda en cualquier parte, pero NVIDIA etiqueta a Switchyard como pre-alfa y experimental, advierte que no es para uso productivo y anticipa que tanto la API como los algoritmos van a cambiar de manera significativa antes de la versión 1.0. Por ahora es una herramienta de evaluación.

Qué hace exactamente Switchyard

Los clientes conservan su API nativa. Switchyard decodifica el pedido entrante hacia tipos de Rust neutrales respecto del proveedor, ejecuta un algoritmo de ruteo para elegir un backend, vuelve a codificar el pedido en el formato de cable de ese backend, lo llama y traduce la respuesta, incluidos los eventos de streaming, de vuelta a la forma que el cliente espera.

El servidor acepta tres formatos entrantes: OpenAI Chat Completions, OpenAI Responses y Anthropic Messages. Cualquiera de los tres puede dirigirse a cualquier ruta, y cada cliente configurado elige su propio formato de salida. Ese desacople es el punto central: la API del agente y la del backend ya no tienen que coincidir.

Tres formas de ejecutarlo

La vía del lanzador apunta a los agentes de programación. Se instala la herramienta publicada con uv tool install --python 3.12 "nemo-switchyard[cli]" y luego se ejecuta switchyard launch claude, switchyard launch codex o switchyard launch openclaw contra un despliegue empaquetado o un archivo TOML propio.

La vía del servidor instala el proxy autónomo con cargo install --locked switchyard-server, valida una configuración con --dry-run y sirve en el host y puerto que se elija.

La vía de biblioteca usa switchyard-libsy, que embebe los algoritmos de ruteo en una aplicación Rust sin hacerse cargo de la pila HTTP. Nunca llama al modelo por su cuenta: el algoritmo decide qué destino usar y devuelve cada llamada al invocador.

Los cuatro algoritmos de ruteo

Una ruta es un identificador de modelo visible para el cliente más el algoritmo que corre detrás. El servidor soporta:

  • passthrough envía todos los pedidos a un único destino.
  • random reparte el tráfico entre destinos con pesos relativos opcionales, y una semilla opcional que reproduce la secuencia de selección. Es la vía para pruebas A/B y experimentos de costo.
  • llm_classifier llama a un destino clasificador para obtener un veredicto de capacidad y luego enruta hacia un destino débil o fuerte. El parámetro base_threshold es obligatorio; min_confidence, capability_elevated_floor y session_affinity lo ajustan, y todo lo que el juez no logre decidir cae al destino fuerte. Con mode = "escalation" cada turno corre primero en el nivel débil y un juez decide si conviene repetirlo en el fuerte.
  • stage_router puntúa señales de resultados de herramientas y de progreso del agente en los turnos recientes para elegir un destino capaz o uno eficiente, evitando la llamada extra al clasificador en la mayoría de los turnos.

Fuerte, débil, capaz y eficiente son roles dentro de una ruta, no propiedades fijas de un modelo. El mismo modelo puede cumplir roles distintos en rutas distintas.

Qué se puede medir

GET /metrics devuelve texto en formato Prometheus desde el proveedor OpenTelemetry del servidor. Las familias cubren pedidos, errores, latencia de llamada al modelo, latencia de turno completo, tokens de prompt, de completado, cacheados, de creación de caché y de razonamiento, además de los intentos HTTP hacia arriba por resultado y código. Una etiqueta tier transporta strong o weak para las decisiones distinguibles del clasificador.

La métrica más interesante es switchyard_routing_overhead_ms, que informa el tiempo de ejecución del algoritmo menos la llamada que atendió el pedido. Las llamadas al clasificador no se restan, así que una ruta con clasificador reporta acá su tiempo de clasificación, mientras passthrough y random reportan el costo submilisegundo de elegir un destino. Los intervalos parten en 0,1 ms.

Configuración y credenciales

Un despliegue TOML tiene tres capas: llm_clients define la URL base, el formato de cable, la variable de entorno con la credencial y la política de reintentos; targets liga un identificador de modelo remoto a un cliente; y routes expone un identificador visible para el cliente junto a su algoritmo.

Los secretos nunca quedan en el archivo, porque api_key_env solo nombra una variable de entorno. El parámetro max_retries viene en 2 por defecto y aplica a fallas de transporte, tiempos de espera agotados, respuestas HTTP 408 y 429, y errores 5xx.

Lo esencial

  • Switchyard es un proxy y biblioteca en Rust bajo Apache 2.0 que enruta y traduce tráfico de modelos de lenguaje.
  • Conecta OpenAI Chat, OpenAI Responses y Anthropic Messages en ambos sentidos, incluidos los flujos de streaming.
  • Llegan cuatro tipos de ruta: passthrough, random, clasificador por modelo y enrutador por etapas guiado por señales.
  • Las métricas de Prometheus aíslan el sobrecosto de ruteo respecto de la latencia de la llamada al modelo, por modelo y por nivel.
  • Es pre-alfa y explícitamente no apto para producción, así que conviene tratarlo como herramienta de evaluación.

El repositorio en GitHub y la documentación están abiertos.