Precios de OpenRouter: costes de peticiones, comisiones y BYOK

Para calcular un presupuesto preciso en OpenRouter, es necesario separar el coste de las peticiones procesadas del dinero que ingresas como saldo en tu cuenta. Además, debes analizar de forma independiente las reglas de BYOK (Bring Your Own Key) si conectas tus propias credenciales de API del proveedor. Una única tarifa de «por millón de tokens» no contempla todos estos componentes de gasto.

El precio del modelo y las recargas de saldo son conceptos distintos

Según el FAQ oficial, el coste de las peticiones se descuenta de tu saldo de créditos prepagados, y el precio depende del modelo y del proveedor subyacente. OpenRouter afirma que traslada las tarifas de los proveedores sin aplicar sobrecostes a la inferencia; la comisión de la plataforma se aplica al adquirir créditos. En la página de precios a 14 de septiembre de 2026, la comisión indicada para el plan Pay-as-you-go es del 5.5%.

Antes de realizar un pago, compara tres datos: la cantidad de créditos que vas a recibir, la comisión que se muestra y el importe final que se cargará a tu método de pago. Comprueba en el cálculo de la pasarela de pago si existen comisiones mínimas por transacción, impuestos aplicables o recargos según la forma de pago. El porcentaje publicado en una tabla de precios no sustituye al importe total definitivo de la compra.

Veamos un ejemplo teórico: si al adquirir $100 en créditos se añade únicamente una comisión de la plataforma del 5.5%, el pago total ascenderá a $105.50. Se trata de una ilustración aritmética sin incluir impuestos, comisiones por cambio de divisa u otros recargos de procesamiento, no de una captura exacta de la pasarela. Tras consumir $20 en créditos, el saldo restante será de $80; no se debe imputar todo el pago inicial como coste exclusivo de esas primeras peticiones.

Cómo estimar tu carga de trabajo real

Para un escenario estándar de texto sin almacenamiento en caché de prompts ni funciones de pago adicionales:

request_cost = input_tokens / 1000000 * input_price
             + output_tokens / 1000000 * output_price

Tomemos una tarifa real de BetterToken para glm-5.3 dentro del grupo GLM, verificada el 14 de septiembre de 2026 en el catálogo de precios actual. En dólares estadounidenses por millón de tokens, el precio de entrada es de $1.232 y el de salida es de $3.872. Para 8 000 tokens de entrada sin caché y 2 000 tokens de salida, el cálculo es el siguiente:

input_cost = 8000 / 1000000 * 1.232 = $0.009856
output_cost = 2000 / 1000000 * 3.872 = $0.007744
total_cost = $0.0176
1000_requests = $17.60

BetterToken no añade ninguna comisión adicional sobre este coste: para este volumen, el total se mantiene en $0.0176 por petición o $17.60 por cada mil peticiones idénticas. No es necesario multiplicar esta cifra por 1.055: las comisiones de depósito de OpenRouter no se aplican a BetterToken. La cantidad de tokens en este ejemplo es ilustrativa; la tarifa proviene directamente del catálogo activo y no de un modelo ficticio. Los tokens en caché y las llamadas a herramientas adicionales no están incluidos en este cálculo. Este ejemplo sirve para ilustrar el cálculo en BetterToken, no como una comparación directa de precios frente a GLM-5.3 en OpenRouter.

Para transformar este cálculo en un presupuesto operativo realista, mide el tamaño real de tus peticiones, incluyendo el historial completo de la conversación y las instrucciones del sistema. Evalúa por separado las consultas cortas y el procesamiento de contextos largos. En el caso de agentes autónomos, suma todas las llamadas intermedias necesarias hasta dar por válido el resultado, en lugar de presupuestar únicamente la respuesta final. Cualquier reintento provocado por una respuesta no válida también debe registrarse en tu control de gastos si generó una llamada facturable a la API.

El almacenamiento en caché de prompts, la entrada de imágenes, los tokens de razonamiento y los recargos por petición pueden alterar el cálculo de costes: comprueba las unidades de facturación específicas en la ficha de cada modelo. El consumo se audita a través del registro de Activity. Para comparar con BetterToken, consulta su página de precios y tus propios registros de uso en Workspace, donde figuran el modelo, el número de tokens y el gasto acumulado. Compara siempre una misma carga de trabajo con las mismas unidades de tarificación; ver dos tablas de tarifas distintas no basta por sí solo para determinar qué alternativa resultará más económica.

El acceso gratuito no significa una capacidad de procesamiento ilimitada

La página de precios especifica un límite de 50 peticiones al día para el plan gratuito. Esta cuota no constituye una garantía general de servicio para cualquier tipo de cuenta ni para rutas alternativas de pago. La documentación sobre límites de velocidad distingue entre los límites de gasto y los límites de frecuencia de peticiones: un error HTTP 402 requiere revisar el saldo de la cuenta y el límite asignado a la clave de API, mientras que un código de estado HTTP 429 puede originarse tanto en la plataforma de OpenRouter como en el proveedor upstream.

Cuando recibas un error HTTP 429, revisa el cuerpo de la respuesta y la cabecera Retry-After si está disponible, e introduce pausas exponenciales entre intentos. Evita crear bucles de reintentos infinitos. Si tus reglas de enrutamiento derivan hacia un modelo de pago como alternativa, incluye el coste de ese modelo en tu presupuesto antes del despliegue. Aunque una ruta gratuita resulta útil para validar la compatibilidad técnica, cualquier flujo crítico en producción requiere un plan de contingencia claro ante fallos del servicio o agotamiento de cuotas.

BYOK: verifica ambas facturas

BYOK (Bring Your Own Key) permite enrutar peticiones a través de OpenRouter utilizando la clave de API de tu propio proveedor upstream. Según la página de precios a 14 de septiembre de 2026, el plan Pay-as-you-go incluye hasta $25 000 al mes de inferencia a precio de catálogo sin comisión por BYOK; una vez superado ese umbral, se aplica una comisión de plataforma del 5%. Esta cifra representa un límite monetario para la exención de recargos: no supone una asignación de peticiones gratuitas ni implica que OpenRouter abone la factura de tu proveedor upstream.

La gestión de claves se realiza en la interfaz de BYOK del espacio de trabajo. Según la documentación de BYOK, el enrutamiento de peticiones sigue una jerarquía estricta: el tráfico recurre primero a las claves prioritarias (Prioritized keys), pasa después a los endpoints compartidos de OpenRouter (shared OpenRouter endpoints) si es necesario, y finalmente recurre a las claves de reserva (Fallback keys), siempre sujeto a los filtros de modelos y directivas de enrutamiento configurados. Derivar tráfico a la infraestructura compartida consume saldo de créditos de OpenRouter. Asimismo, los presupuestos del espacio de trabajo y los límites de seguridad (guardrail budgets) excluyen por defecto el gasto efectuado vía BYOK; si se desea contabilizarlo, debe activarse explícitamente mediante el ajuste «Include BYOK spend».

Para configurar y validar tu canal de BYOK, sigue estos pasos:

1. Verifica permisos y filtros: confirma que la clave de API de tu proveedor cuenta con los permisos necesarios para los modelos requeridos y define los filtros de modelos correspondientes en OpenRouter.
2. Define la directiva de prioridad de claves: establece el orden de uso entre las distintas claves y determina si se autoriza la derivación de peticiones hacia endpoints compartidos de OpenRouter o claves de reserva (Fallback keys).
3. Separa las partidas presupuestarias: asigna límites de gasto independientes: uno directo con tu proveedor upstream y otro en tu saldo de OpenRouter para cubrir el uso de capacidad de reserva o la comisión del 5% tras rebasar el umbral mensual exento.
4. Ejecuta una única petición de prueba: envía una petición acotada, abre el registro de Activity con la opción View Raw Metadata, comprueba el bloque provider_responses y contrasta los datos registrados con las facturas reales emitidas por tu proveedor. No des por sentado que la atribución de costes automática coincide a la perfección con la facturación del proveedor sin comprobarlo de primera mano.

Si una única API directa cubre tus necesidades operativas, compara su factura final con la de gestionar ese mismo volumen a través de OpenRouter. Si necesitas redundancia multimodelo o enrutamiento dinámico, pondera la ventaja arquitectónica de contar con facturación unificada e interfaces estandarizadas. Para una primera evaluación, basta con un lote de tareas pequeño y delimitado: el coste total por cada resultado aceptado aporta mucha más información que comparar de forma aislada la tarifa base por token.