Añade APIsRouter como endpoint personalizado en LibreChat.

Respuesta rápida: un bloque en librechat.yaml.

Los endpoints personalizados de LibreChat se configuran en librechat.yaml bajo endpoints.custom, un array donde cada entrada es un proveedor. Los tres campos que importan son name (la etiqueta en el selector de endpoints), apiKey (que interpola variables de entorno con la forma ${VARIABLE}, así que la clave vive en .env y nunca en el YAML) y baseURL. Para APIsRouter el baseURL es https://api.apisrouter.com/v1, con el /v1 incluido, porque LibreChat añade rutas como /chat/completions a cualquier base que le des. El bloque models decide qué aparece en el desplegable de modelos. Pon models.fetch en true y LibreChat consulta el listado /v1/models del endpoint al cargar, así que cada id del catálogo se vuelve seleccionable sin mantener una lista escrita a mano. models.default sigue siendo obligatorio como array y sirve de respaldo mostrado antes de, o en lugar de, un fetch. Esto es configuración documentada aguas arriba, no un parche: la estructura del objeto de endpoint personalizado en la documentación de LibreChat define cada clave usada aquí.

version: 1.2.1
endpoints:
  custom:
    - name: "APIsRouter"
      apiKey: "${APISROUTER_API_KEY}"
      baseURL: "https://api.apisrouter.com/v1"
      models:
        default: ["claude-sonnet-4-6"]
        fetch: true

Cómo enruta LibreChat los endpoints personalizados.

LibreChat (danny-avila en GitHub, con unas 41K estrellas) es la interfaz autoalojada al estilo ChatGPT más desplegada: multiusuario, multimodelo, con búsqueda de conversaciones, agentes, manejo de archivos y claves por usuario. A diferencia de los clientes que fijan una lista de proveedores en el código, su array endpoints.custom acepta cualquier servicio compatible con OpenAI, y varios proveedores conocidos en la documentación se configuran exactamente con este mecanismo. Cuando un usuario elige un modelo de un endpoint personalizado, LibreChat envía una petición estándar de /v1/chat/completions al baseURL de ese endpoint con el campo model como una cadena simple. Nada en el cliente le importa qué proveedor entrenó el modelo; la cadena se reenvía tal cual. Cuando el endpoint detrás del baseURL sirve a varios proveedores, una sola entrada en librechat.yaml pone los ids de Claude, GPT, Gemini, DeepSeek y GLM en el mismo desplegable, y un usuario cambia de proveedor a mitad de conversación de la misma forma que cambiaría entre dos variantes de GPT. Eso colapsa la configuración multiproveedor habitual de LibreChat. En lugar de una entrada personalizada por proveedor, cada una con su propia clave en .env y su propia superficie de facturación, una entrada con una clave cubre el catálogo, y el administrador ve el uso por modelo en un solo sitio en vez de conciliar varios paneles.

Configuración completa: YAML, .env y el montaje de Docker.

Crea librechat.yaml en la raíz del proyecto y pon la clave en .env. La referencia ${APISROUTER_API_KEY} en el YAML se resuelve desde el entorno al arrancar, así que el archivo de configuración se puede seguir versionando (commit). El paso que más se saltan las configuraciones de primera vez es específico de Docker: el contenedor no ve tu librechat.yaml hasta que lo montas. La documentación indica crear docker-compose.override.yml con un bind mount de ./librechat.yaml a /app/librechat.yaml, y luego recrear los contenedores. Editar el YAML después también requiere un reinicio, porque el archivo se lee al arrancar, no se vigila en caliente. Vale la pena configurar algunos campos opcionales en una entrada de gateway. titleConvo activa los títulos automáticos de conversación, y titleModel elige el modelo que los escribe; el valor por defecto documentado de LibreChat para titleModel es gpt-3.5-turbo, un id que un endpoint que no sea de OpenAI puede no servir, así que configúralo explícitamente con un id rápido del catálogo o con el valor especial current_model. modelDisplayLabel controla el nombre mostrado en los mensajes del asistente. Y apiKey acepta el valor especial user_provided si quieres que cada usuario pegue su propia clave en vez de compartir la del servidor.

version: 1.2.1
endpoints:
  custom:
    - name: "APIsRouter"
      apiKey: "${APISROUTER_API_KEY}"
      baseURL: "https://api.apisrouter.com/v1"
      models:
        default: ["claude-sonnet-4-6", "gpt-5.5", "deepseek-v4-pro"]
        fetch: true
      titleConvo: true
      titleModel: "claude-haiku-4-5-20251001"
      modelDisplayLabel: "APIsRouter"

Elegir modelos para un espacio de chat compartido.

Como todos los modelos facturan a través de la misma clave, el bucle práctico para un administrador es observar una semana de uso en la consola, ver qué modelos eligen realmente los usuarios, y podar models.default en consecuencia, manteniendo fetch activo para que los usuarios avanzados sigan pudiendo llegar a la lista completa.

• El chat de uso diario quiere un generalista sólido. claude-sonnet-4-6 y gpt-5.5 sostienen conversaciones largas, discusión de archivos y ejecuciones de agente sin ansiedad de modelo por mensaje.
• Las preguntas cortas y frecuentes son trabajo de volumen. claude-haiku-4-5-20251001 y gemini-3.5-flash responden rápido y evitan que un despliegue con muchos usuarios concentre el gasto en turnos desechables.
• La generación de títulos se dispara en cada conversación. Apunta titleModel a un id rápido; pagar tarifas de vanguardia para escribir títulos de seis palabras es el desperdicio silencioso más común en un despliegue de LibreChat.
• Los equipos multilingües deberían probar deepseek-v4-pro y glm-5.2 con su mezcla real de idiomas; un desplegable multiproveedor convierte eso en una comparación dentro de la app en lugar de una reconfiguración.
• models.fetch significa que los modelos nuevos del catálogo aparecen sin tocar el YAML, así que un modelo añadido aguas arriba se vuelve seleccionable la próxima vez que se actualice la lista.

Pago por uso · por debajo del precio oficial

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Modos de fallo específicos de LibreChat.

El clásico es que la configuración no cargue en silencio, y casi siempre es el montaje de Docker. Sin el bind mount de docker-compose.override.yml, el contenedor corre sin ningún librechat.yaml, el endpoint personalizado nunca aparece en el selector, y nada da error. Confirma que el archivo existe dentro del contenedor antes de depurar cualquier otra cosa. Una apiKey que llega literalmente como ${APISROUTER_API_KEY} significa que la variable no estaba presente en el entorno con el que arrancó el servidor; la interpolación ocurre al arrancar desde .env, así que una clave añadida después necesita un reinicio del contenedor. El síntoma es un 401 del gateway con un bearer token sin sentido. Un baseURL sin /v1 produce 404 en cada petición, porque LibreChat añade /chat/completions a la base tal como se dio. El error inverso, pegar una URL completa de completions como baseURL, pertenece a la opción independiente directEndpoint y no debería combinarse con una entrada normal. Un desplegable de modelos vacío con fetch desactivado significa que models.default falta o está vacío; es un array obligatorio. Con fetch activado, un desplegable vacío suele significar que el propio fetch falló, lo que nos devuelve a la clave o al baseURL. Y los títulos de conversación fallidos en un endpoint que por lo demás funciona son el valor por defecto de titleModel apuntando a un id que el gateway no sirve; configúralo explícitamente.

Quién enruta LibreChat a través de un gateway.

• Equipos que autoalojan un espacio de chat compartido y quieren Claude, GPT, Gemini y DeepSeek en un solo desplegable sin mantener una entrada endpoints.custom y una cuenta de proveedor por cada uno.
• Administradores que gestionan despliegues multiusuario y necesitan una sola superficie de uso. Los registros por clave muestran qué modelos usa realmente el equipo, con su coste, sin fusionar paneles de proveedores.
• Operadores que dan a cada departamento su propia clave: el mismo YAML, una clave por grupo, y el registro de uso se convierte en el informe de coste por equipo.
• Hogares y grupos pequeños que sustituyen varias suscripciones de chat por un solo endpoint medido, pagando por los tokens usados en lugar de por asientos.
• Desarrolladores sin acceso a la facturación de un proveedor concreto. El acceso basado en recargas sin requisito de tarjeta elimina la dependencia de registrarse en cada proveedor.

Verifica el endpoint y depura el primer mensaje.

Comprueba la mitad del gateway antes de tocar LibreChat: lista los modelos con tu clave y confirma que aparecen los ids que pusiste en models.default. Si eso funciona, cualquier síntoma restante está en el lado de LibreChat de la conexión. Luego arranca el stack y abre el selector de endpoints. Que la entrada de APIsRouter aparezca ya demuestra que el YAML cargó; que la lista de modelos se rellene demuestra el fetch y la clave; que llegue la primera respuesta demuestra la ruta de chat. Trabaja esos tres puntos en orden en vez de todos a la vez, porque cada uno tiene un conjunto de fallos distinto: el montaje, la variable de entorno y el baseURL respectivamente. Una vez que fluyen los mensajes, la consola de APIsRouter muestra el modelo, el recuento de tokens y el gasto por petición. Una instancia compartida de LibreChat es exactamente el tipo de despliegue donde el uso se concentra calladamente en dos o tres modelos, y el registro de uso es cómo te enteras de cuáles antes que la factura.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

Preguntas frecuentes