Comprobación diaria: el modelo que responde es el que se indica
Cada modelo recibe el mismo prompt de prueba una vez al día y su respuesta se compara con los resultados anteriores. Un relay que cambia el modelo que hay detrás de un id aparece como cambiado, y los resultados están abiertos al público sin API key.
01Cómo funciona la comprobación diaria
Cada modelo del catálogo recibe una vez al día el mismo prompt canary. Su respuesta se compara con las de las pruebas anteriores y cada modelo recibe un estado junto con la hora de la prueba. Los resultados actuales por modelo están en la página proof (en inglés).
Los mismos datos están disponibles como JSON público en https://api.relayswitch.io/v1/proof: sin API key, legible desde cualquier origin y con una caché de cinco minutos. Los id de modelo que se prueban son los mismos de la lista de modelos.
02Qué significan los tres estados
Cada modelo recibe uno de los tres estados de abajo. Pasar la comprobación significa que la respuesta de ese id hoy es la misma que antes y que su ruta responde. Lo que se descarta es la sustitución del modelo y las rutas caídas; para tu propio caso de uso, sigue ejecutando tus propios prompts.
| Estable | El modelo responde al prompt canary igual que en las pruebas anteriores. |
| Cambiado | La respuesta se ha desplazado respecto a la prueba anterior: quien atiende ese id ya no es quien lo atendía. |
| Inaccesible | Ninguna ruta de ese modelo respondió en la última prueba; el estado anterior es solo historial, no la situación actual. |
03Un recibo firmado por cada petición
La comprobación diaria responde a la pregunta sobre el modelo; el recibo responde a la pregunta sobre una petición concreta. Envía una petición pequeña, toma el id de petición del header de la respuesta y pide su recibo en GET https://api.relayswitch.io/v1/requests/:id/receipt. El recibo lleva una firma Ed25519 y registra el modelo, los tokens cobrados y el costo, así que se puede verificar offline con la public key y no se puede alterar después.
La página de verificación de recibos (en inglés) comprueba la firma sin necesidad de cuenta. Hay más ejemplos de peticiones en la página de Claude API.
curl -i https://api.relayswitch.io/v1/messages \ -H "Authorization: Bearer sk-relay-..." \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{"model": "claude-fable-5.1", "max_tokens": 16, "messages": [{"role": "user", "content": "Reply with ok"}]}'04Probar cualquier relay: empieza con una recarga pequeña
Antes de confiar en cualquier relay, recarga lo mínimo posible y ejecuta las siete pruebas de la sección siguiente. El objetivo es tener evidencia antes de confiar: si las pasa, recargas más; si no, la pérdida es limitada. Empieza pidiendo la lista de id de modelo que tu key puede llamar, porque cada prueba necesita el id exacto.
curl https://api.relayswitch.io/v1/models \ -H "Authorization: Bearer sk-relay-..."05Siete pruebas que puedes ejecutar por tu cuenta
Las tres primeras se hacen en media hora; las otras cuatro hay que ejecutarlas durante varios días.
| Declaración de identidad | Pregúntale al modelo qué modelo es y quién lo desarrolló. Esto solo descarta la suplantación más burda, porque una frase en el system prompt hace que cualquier modelo diga ser GPT o Claude. Una respuesta correcta no demuestra nada; una respuesta errónea o incoherente sí es una señal. |
| Fecha de corte de conocimiento | Pregunta por varios hechos posteriores a la fecha de corte de los datos de entrenamiento de ese modelo y por varios anteriores. El modelo real dirá que no conoce los posteriores; un modelo antiguo que se hace pasar por él falla también en hechos poco anteriores al corte. Anota la fecha que anuncia el desarrollador y pregunta por tres hechos a cada lado. |
| Una contraseña en un contexto largo | Envía un texto largo sin relación, mete una contraseña en medio y pregunta cuál es. El modelo indicado la encuentra exacta mientras esté dentro de su ventana de contexto; un modelo de ventana pequeña o una ruta que recorta el contexto falla o se la inventa. Escribe el texto tú mismo. |
| Canary de aritmética o de código | Una multiplicación de muchos dígitos con una única respuesta, o un código que exige un output exacto. Un modelo destacado acierta de forma constante; cuando lo degradan a un modelo pequeño, la tasa de error sube con claridad. Pregunta cinco veces y anota aciertos y fallos. |
| Comparación del número de tokens | Cuenta tu input con el tokenizer del desarrollador y compáralo con prompt_tokens en el usage de la respuesta; haz lo mismo con el output y completion_tokens. Una diferencia grande significa que el cobro no sigue al modelo indicado o que la petición se reescribe. |
| Consistencia durante varios días | Convierte las pruebas anteriores en un script, ejecútalo cada día a la misma hora y guarda las respuestas. El día en que cambian la ruta, las respuestas cambian en conjunto. Pasar una vez no significa pasar siempre. |
| Revisión de los recibos | Pide un recibo por petición que incluya el id del modelo, los tokens cobrados, el costo y una firma. Un recibo así se puede verificar offline con la public key. En un relay sin recibos, solo cuentas con tus propios registros. |
06Una pregunta canary y lo que se les escapa a los detectores
Pon temperature en 0 y envía una sola frase: calcula 48213 × 7391 y escribe solo el número, y luego di en una frase hasta qué mes y año llegan tus datos de entrenamiento. La única respuesta correcta es 356342283, y el mes de corte se coteja con la fecha que anuncia el desarrollador. Un modelo sustituto falla en una de las dos cosas: la multiplicación sale mal, algo habitual en modelos pequeños y versiones cuantizadas, o el mes de corte que da no es el del modelo indicado.
Los detectores de relays que circulan trabajan en tres capas: revisión de los campos de protocolo de la respuesta, huella de estilo a partir de varias rondas de prompts y curva de capacidad con preguntas cada vez más difíciles. Hay dos cosas que se les escapan a las tres. La primera, el multiplicador de precio: la petición se reenvía tal cual al modelo real y luego se cobra más cara, así que las revisiones de protocolo y de estilo salen todas bien. Solo se ve si se multiplican los tokens cobrados del recibo por el precio de la página del modelo y se coteja con el saldo descontado. La segunda, las versiones cuantizadas: una versión de baja precisión del mismo modelo puede acertar una pregunta, pero su curva de capacidad baja, así que hay que ejecutar el mismo conjunto de preguntas durante varios días. Cómo se cobra aquí se explica en la página de precios.
Preguntas frecuentes
- El modelo dice ser GPT o Claude, ¿puedo confiar en eso?
- No como única base. Una frase en el system prompt hace que cualquier modelo diga cualquier nombre. Mira si responde bien sobre hechos posteriores a su fecha de corte de conocimiento, si encuentra la contraseña en un texto largo y si calcula bien.
- ¿Cómo se hace la comprobación diaria?
- Cada modelo del catálogo recibe el mismo prompt de prueba una vez al día y su respuesta se compara con las de las pruebas anteriores. Hay tres estados: estable, cambiado e inaccesible. El resultado es un JSON público en https://api.relayswitch.io/v1/proof, sin API key.
- ¿Cómo se verifica un recibo?
- GET https://api.relayswitch.io/v1/requests/:id/receipt devuelve un recibo con firma Ed25519 que registra el modelo, los tokens cobrados y el costo. La firma se comprueba con la public key y no hace falta cuenta.
- ¿Pasar la comprobación significa que el modelo es auténtico seguro?
- La comprobación muestra que la respuesta de ese id hoy es la misma que antes y que su ruta responde. Lo que se descarta es la sustitución del modelo y las rutas caídas. Para tu propio caso de uso, vuelve a probar con tus propios prompts.
- ¿Cómo sé si han degradado un modelo a escondidas?
- Degradar a escondidas es sustituir el mismo id por un modelo más débil o por una versión cuantizada. Envía una vez al día la misma pregunta de respuesta única con temperature 0: si la respuesta pasa de correcta a incorrecta, o cambia el mes de corte de conocimiento, el modelo ya es otro. Después mira el recibo: si el id del modelo sigue igual pero la respuesta cambia, lo que cambió es el modelo y no tu prompt. La comprobación diaria de aquí marca esa situación como cambiado.
- ¿Por qué empezar las pruebas con una recarga pequeña?
- Porque el objetivo de las pruebas es tener evidencia antes de confiar. La recarga mínima aquí es de $10, suficiente para ejecutar las siete pruebas varias veces. Si las pasa, recargas más; si no, la pérdida es limitada. Las recargas no son reembolsables.
Primero prueba, después confía
Recarga $10 y ejecuta las siete pruebas. Cada modelo se comprueba una vez al día de forma pública, y cada petición tiene un recibo firmado.