Un solo endpoint. El modelo correcto: aprendido, no supuesto.

Switchyard se coloca entre su asistente y los modelos. Para cada solicitud elige el modelo más económico que todavía resuelve la tarea, medido contra un benchmark en vivo y no con una regla escrita a mano. Es independiente del modelo y del proveedor, y lo bastante rápido para ir directamente en la ruta de cada solicitud. Usted cambia una sola línea: su URL base.

client = OpenAI(
  base_url=YOUR_SWITCHYARD_ENDPOINT,            # ← la única línea que cambia
  api_key=...,
)

client.chat.completions.create(
  model="auto",                                 # ← deje que Switchyard elija
  messages=[...],
)

Mantenga model="auto" para que Switchyard enrute, o indique un modelo cuando quiera y la solicitud pasa directo. Habla la misma API que usted ya usa.

Hoy Switchyard funciona en acceso anticipado, instalado junto a la aplicación a la que sirve y no como un endpoint público: la URL base es suya, no nuestra. Hable con nosotros sobre una instalación.

Cómo funciona

Agregar un enrutador suele significar agregar otra llamada a un modelo, con su latencia, a cada solicitud. Switchyard no. La mayoría de las decisiones nunca tocan un modelo:

La consecuencia: el costo de enrutar crece con cuántos tipos de preguntas recibe, no con cuántas preguntas. El tráfico real de un negocio se repite, así que con volumen la decisión adicional es una consulta en memoria que no cuesta nada y no agrega una latencia perceptible.

Como cada solicitud ya pasa por el gateway, es el lugar natural para detectar un secreto antes de que salga. Shieldyard es una capa de seguridad dentro de Switchyard que vigila las dos direcciones de un turno en busca de credenciales filtradas: el prompt que sale hacia el modelo y la respuesta del modelo que regresa en streaming.

• Revisa el prompt que sale hacia el modelo en busca de secretos de proveedores: claves de API, tokens, llaves privadas y asignaciones con forma de secreto
• También revisa la respuesta del modelo que regresa en streaming: una filtración puede aparecer en la salida, incluso partida entre fragmentos
• Observa por defecto: registra cada hallazgo sin modificar su tráfico; en el prompt de salida, el bloqueo (ocultar el secreto antes de enviarlo) se activa por asistente si usted lo pide
• La revisión de la respuesta en streaming hoy solo observa: detecta y reporta, y reenvía los bytes tal cual; todavía no elimina un secreto de un stream en vivo
• Auditoría que protege la privacidad: guarda un hash con sal de la coincidencia y la regla que se activó, nunca el valor del secreto

Alcance real, hoy: Shieldyard detecta secretos de proveedores (no datos personales en general) y por defecto se limita a observar (registra los hallazgos sin alterar su tráfico) hasta que usted activa el bloqueo para un asistente, que hoy aplica al prompt de salida. Ocultar secretos a mitad del stream de regreso, aplicarlo en todas partes, una capa para más tipos de datos y un clasificador de prompt injection de entrada son lo que estamos construyendo encima.

El mismo gateway que detecta un secreto filtrado es también el único lugar que puede impedir que un solo prompt desbocado aumente la factura sin que nadie lo note. Límites fija por asistente un tope de cuántos tokens puede costar un turno (el largo de la respuesta, el tamaño de la entrada y un valor razonable cuando quien llama olvida fijarlo) y lo aplica antes de llamar al proveedor del modelo.

Alcance real, hoy: los topes se fijan por asistente y por defecto se limitan a observar (registran lo que un tope habría hecho con su propio tráfico, sin cambiar nada) hasta que usted cambia uno a modo de aplicación (recortar la solicitud o rechazarla). Acota los tokens de entrada y salida de un turno; no mide el tiempo transcurrido a mitad del stream. Los topes se dimensionan con la auditoría medida de lo que su tráfico real habría alcanzado.

Basado en tres compromisos

Lo que obtiene

• Un endpoint compatible con OpenAI listo para conectar: cambie su URL base y nada más
• Enrutamiento independiente del modelo y del proveedor (Anthropic, OpenAI, Groq y más)
• La calidad primero: el modelo más económico que todavía cumple, nunca una baja que le cueste precisión
• Decisiones de enrutamiento en una fracción de la solicitud: una consulta, no otra llamada lenta a un modelo
• Un tablero en vivo de qué se envió a dónde y del ahorro medido
• Sus datos siguen siendo suyos: guárdelos con nosotros para afinar o consérvelos en su propio almacenamiento

La objeción que se gana todo enrutador automático: «¿y si me baja de modelo sin avisar?». La respuesta no es una promesa, sino un registro:

• Los modelos candidatos se prueban en paralelo con su tráfico real antes de poder proponerse: responden las mismas preguntas reales, sin que nadie lo vea, y se califican
• Un juez de calidad filtra cada propuesta: un modelo más económico tiene que mantener la calidad de resolución o nunca se sugiere; el ahorro que cuesta precisión se descarta automáticamente
• Los cambios de enrutamiento se entregan como un paquete de rutas versionado por cliente, marcado con la corrida de benchmark que lo produjo: cualquier decisión se puede rastrear hasta la evidencia con la que se compiló
• Los cambios de enrutamiento se pueden revertir: se conservan sus últimos 20 paquetes de rutas reemplazados y podemos volver a poner uno en servicio con un solo comando. Una restauración queda marcada como tal en el paquete y también se puede deshacer. Dura hasta la siguiente recompilación del enrutamiento (programada a diario) o hasta otro cambio
• Cuando un proveedor anuncia el retiro de un modelo, medimos el reemplazo y proponemos el cambio antes de la fecha límite: los retiros de modelos dejan de ser caídas del servicio