Comisiones BYOK, fallback y rotación de claves en OpenRouter (2026)

Tu clave de OpenAI puede ser válida, la solicitud puede completarse correctamente y, aun así, tu saldo de OpenRouter puede bajar. BYOK en OpenRouter no activa un único mecanismo de facturación: el coste del proveedor, la comisión de plataforma y la capacidad de fallback se gestionan por vías distintas. Además, la regla actual ya no se basa en el anterior límite de un millón de solicitudes.

Primero, identifica qué cargo estás investigando

OpenRouter BYOK permite enviar una solicitud usando una credencial del proveedor almacenada en tu workspace, mientras OpenRouter sigue funcionando como capa de API y enrutamiento. De ahí salen tres flujos de coste independientes:

La primera pregunta de diagnóstico no es «¿Añadí mi clave?», sino «¿qué proveedor atendió realmente esta solicitud?». Una clave configurada puede fallar por límites de tasa, falta de fondos en el proveedor, permisos o una caída temporal del servicio. Si el fallback está activado, OpenRouter puede completar la solicitud a través de otro proveedor y cargar esa ruta a tu saldo de OpenRouter, tal como explica su artículo de soporte sobre cargos BYOK.

Qué cambia BYOK en OpenRouter y qué no

BYOK dirige el tráfico compatible mediante la credencial de tu proveedor, pero mantiene la API y la capa de enrutamiento de OpenRouter. Según la documentación de BYOK, las credenciales se cifran y se utilizan para solicitudes encaminadas a través del proveedor indicado.

BYOK no hace que la inferencia sea gratuita: el proveedor sigue facturando el uso del modelo, y OpenRouter puede aplicar una comisión de plataforma independiente tras superar la asignación correspondiente. Usar tu propia clave tampoco evita las reglas de privacidad a nivel de workspace, cuenta o solicitud; si no queda ningún endpoint apto, la solicitud falla incluso cuando la credencial es válida.

La comisión BYOK actual depende del valor de la inferencia, no del número de solicitudes

La página actual de precios de OpenRouter calcula la asignación BYOK sin comisiones a partir del valor de la inferencia a precio de lista, no del volumen de solicitudes:

La asignación se mide según lo que normalmente costaría en OpenRouter ese mismo modelo con ese proveedor, no necesariamente según la factura negociada con tu proveedor. Una vez agotada, la comisión BYOK del 5% se descuenta de tus créditos de OpenRouter; el cargo del proveedor sigue siendo independiente.

Tres costes que conviene contabilizar por separado

1. Coste de inferencia del proveedor: el proveedor factura a la cuenta asociada a la credencial BYOK.
2. Comisión de plataforma BYOK: OpenRouter cobra un 5% después de la asignación vigente de tu plan, usando créditos de OpenRouter.
3. Coste de inferencia por fallback: los créditos de OpenRouter cubren una ruta que utilizó capacidad de un proveedor financiada por OpenRouter en lugar de la ruta BYOK prevista.

Las comisiones por comprar créditos constituyen otra partida: los precios de OpenRouter indican una comisión de plataforma del 5.5% para el plan Pay-as-you-go. Un cargo por recarga no demuestra que una solicitud concreta haya usado fallback.

Por qué sigue apareciendo en las búsquedas la cifra de 1 millón de solicitudes

El anuncio de OpenRouter de octubre de 2025 hablaba de un millón de solicitudes BYOK al mes sin comisión de plataforma, seguido de una comisión del 5%. Esa era la política histórica recogida en el anuncio fechado; la página ahora indica que los precios de BYOK cambiaron en agosto de 2026. Para hacer estimaciones, utiliza la asignación actual basada en inferencia a precio de lista y anota la fecha de consulta.

El fallback determina si BYOK es un límite estricto

El objetivo predeterminado del enrutamiento de OpenRouter es completar la solicitud. La guía de BYOK distingue las claves prioritarias, los endpoints compartidos de OpenRouter y las claves de fallback como posiciones diferentes dentro de la ruta:

• Las claves BYOK prioritarias se prueban en el orden configurado.
• Si esos intentos fallan, OpenRouter puede probar su capacidad compartida.
• Las claves BYOK marcadas como fallback se prueban después de los endpoints compartidos.
• Varias claves coincidentes del mismo proveedor pueden probarse en orden.

El orden de proveedores añade otro matiz: los endpoints BYOK coincidentes se intentan antes que los endpoints compartidos incluso si ese proveedor aparece más tarde en el array order que has solicitado. Por tanto, una solicitud puede utilizar una clave BYOK antes de lo que sugiere tu regla general de orden de proveedores.

Fiabilidad o certeza de facturación: hay que elegir

La opción del panel Always use for this provider impide que OpenRouter use su credencial compartida para ese mismo proveedor. No es un interruptor global de «no usar nunca créditos de OpenRouter». El artículo de soporte de OpenRouter indica que una solicitud aún puede pasar de una clave BYOK de Anthropic a otro proveedor compatible, como Google Vertex, si el fallback entre proveedores sigue disponible.

Si necesitas certeza de facturación, limita la propia solicitud:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

Con provider.only, un fallo de Anthropic se convierte en un error de API en vez de redirigirse silenciosamente a otro proveedor. Es la opción adecuada para cargas reguladas, acuerdos de datos específicos de un proveedor o informes de coste donde cada solicitud debe asociarse a una única cuenta upstream. No es una buena configuración predeterminada para un producto interactivo en el que la disponibilidad importa más que una titularidad estricta del proveedor.

Un usuario de r/openrouter describió el mismo control:

«puedes especificar proveedores en order/only directamente en la solicitud para obligar a que use únicamente los de tu BYOK». — u/Randomdotmath, Hilo de Reddit

Si el fallback forma parte de tu diseño de fiabilidad, presupuéstalo; si no, desactívalo en el límite de la solicitud.

Revisa la ruta en Activity antes de culpar a la comisión

Según las FAQ de OpenRouter, Activity puede mostrar el historial de uso y filtrarlo por modelo, proveedor y clave de API. Comprueba lo siguiente:

1. Proveedor que atendió la solicitud: ¿coincide con el proveedor vinculado a tu credencial BYOK?
2. Modelo y endpoint: ¿el router eligió otro endpoint compatible?
3. Clave de API de la aplicación: ¿qué clave de entorno o workspace realizó la solicitud?
4. Descuento de créditos: ¿el importe corresponde a gasto de inferencia, a una comisión BYOK o a un cambio de saldo relacionado con una recarga?

Si el proveedor mostrado en Activity es distinto del proveedor BYOK, investiga el fallback antes de cambiar la credencial. Si coincide y el volumen se acerca a la asignación del plan, revisa la comisión de plataforma BYOK. Así evitarás rotar una clave válida para resolver un problema de política de enrutamiento.

Una arquitectura de claves preparada para rotaciones en producción

Trata la clave de aplicación de OpenRouter y la credencial BYOK upstream como secretos distintos, con responsables diferentes:

Configura y prueba una credencial BYOK

Sigue esta ruta breve antes de depurar tráfico de producción:

1. Añade la credencial del proveedor en la configuración BYOK del workspace o créala mediante la API de gestión de BYOK.
2. Asigna un nombre que identifique el proveedor, el entorno y el propósito.
3. Aplica filtros de modelo, de clave de API de OpenRouter o de miembro antes de compartir la credencial del workspace.
4. Coloca la clave en la sección de prioridad y añade una clave de fallback solo si su función de facturación y contingencia está claramente definida.
5. Envía una solicitud de prueba, revisa en Activity qué proveedor la atendió y decide después si debe seguir activado el fallback compartido.

En proveedores cloud, las credenciales no son intercambiables:

Estas condiciones proceden de la documentación específica de BYOK por proveedor de OpenRouter. Un secreto válido con tipo de recurso, región, deployment o permisos incorrectos representa un error de configuración, no una prueba de que BYOK no sea compatible.

La configuración BYOK de OpenRouter admite filtros para slugs de modelos, hashes de claves de API de OpenRouter y miembros del workspace. Todos los filtros activos deben coincidir para que una credencial sea apta, y la documentación permite hasta 100 entradas por filtro. Utiliza listas explícitas de permitidos; divide los equipos grandes por workspaces en lugar de mantener una única credencial cada vez más amplia.

Rota la clave de aplicación de OpenRouter sin rotar las claves del proveedor

El cookbook de rotación de claves de API de OpenRouter describe las credenciales BYOK de proveedores como asociadas a la cuenta de OpenRouter, no a una clave de aplicación concreta. Su secuencia sin interrupciones es la siguiente:

1. Crea una clave de aplicación de OpenRouter de reemplazo con un nombre descriptivo y el límite adecuado.
2. Guárdala en tu gestor de secretos y desplíegala en todos los servicios, trabajos y entornos que usan la clave anterior.
3. Confirma en Activity que el tráfico de producción utiliza la clave de reemplazo.
4. Elimina la clave antigua solo cuando la migración haya terminado.

La documentación de la Management API indica que las claves de la Management API son credenciales administrativas y no pueden llamar a endpoints de completion. La clave de reemplazo debe estar disponible antes de revocar la clave de aplicación anterior.

Rota por separado la credencial del proveedor

La rotación de claves del proveedor es un cambio distinto. Sigue la política de credenciales del propio proveedor y prueba exactamente el modelo, la región, los permisos y la cuota que utiliza la carga de trabajo.

1. Crea la credencial de reemplazo upstream con los permisos mínimos necesarios.
2. Añádela a la conexión BYOK de OpenRouter con un nombre distinto y una prioridad controlada.
3. Envía una solicitud de prueba e inspecciona Activity.
4. Mueve el reemplazo a la posición principal y vigila los errores y el uso del proveedor.
5. Revoca la credencial antigua upstream tras la ventana de solapamiento.

Esta secuencia es una recomendación operativa basada en el comportamiento de prioridades documentado por OpenRouter; las reglas de revocación del proveedor siguen siendo la referencia definitiva. La API de creación de BYOK de OpenRouter acepta una credencial sin procesar, pero indica que se cifra en reposo y no se devuelve en respuestas posteriores de la API. Conserva la credencial de origen en tu propio gestor de secretos: OpenRouter no es una copia de recuperación.

Cuándo BYOK de OpenRouter no debería ser tu opción predeterminada

El acceso directo al proveedor es una mejor opción predeterminada cuando los logs nativos de un único proveedor, el comportamiento exacto de sus endpoints o sus herramientas tienen más importancia que un enrutamiento unificado. BYOK encaja mejor si utilizas varias cuentas de proveedores, ya cuentas con créditos o capacidad comprometida con ellos y necesitas controles a nivel de workspace.

Preguntas frecuentes sobre OpenRouter BYOK

¿OpenRouter sigue cobrando si uso mi propia clave?

Sí. El proveedor puede facturar la inferencia realizada mediante la credencial BYOK; OpenRouter puede descontar de tus créditos una comisión de plataforma BYOK del 5% tras la asignación actual de tu plan; y el fallback puede hacer que tus créditos de OpenRouter cubran una ruta de otro proveedor.

¿«Always use for this provider» bloquea todo el fallback?

No. Impide que OpenRouter utilice su propia credencial compartida para ese proveedor concreto, pero no evita que una solicitud pase a otro proveedor compatible. Usa provider.only cuando esa ruta entre proveedores deba ser imposible.

¿Cómo debe gestionar una empresa la seguridad y los presupuestos de BYOK?

OpenRouter indica que las credenciales se cifran, que las claves sin procesar de los proveedores no se devuelven a través de la Management API y que el gasto BYOK queda excluido por defecto de los guardrails y presupuestos de workspace. La documentación de BYOK indica que debes activar Include BYOK spend o include_byok_in_budgets cuando necesites un presupuesto combinado. Los equipos enterprise también deberían usar credenciales con mínimo privilegio, separación por workspaces, filtros, custodia en un gestor de secretos, rotación y revisión de Activity.

La configuración predeterminada debe responder al tipo de fallo que puedes asumir

Elige los controles de enrutamiento y presupuesto en función de si la finalización de solicitudes, la titularidad del proveedor o la visibilidad de costes es el requisito al que no puedes renunciar.