Modelos y enrutamiento

UberLLM envía cada solicitud a un proveedor externo disponible para el modelo que solicitaste. Si el proveedor falla antes de empezar a responder, la solicitud se reintenta, y una solicitud que sigue fallando no se factura. Cada solicitud se factura lo que el proveedor cobró, sin añadir ninguna tarifa de UberLLM, y se lista con su costo en Dashboard → Activity. Tú eliges un modelo, no un proveedor.

IDs de modelo

Usa el ID de modelo del catálogo, por ejemplo deepseek/deepseek-v4-flash, anthropic/claude-sonnet-5 o z-ai/glm-5.3. Aquí tienes lo que puedes llamar ahora mismo:

• GET https://api.uberllm.dev/v1/models: los modelos de chat a los que se puede enviar una solicitud ahora mismo, de modo que una herramienta que rellene su menú de modelos a partir de esta lista (SillyTavern, LibreChat, n8n, Cline) muestre solo los modelos con los que puede chatear. Añade ?type=video (o image, music, speech, transcription, audio para ambos, chat, varios unidos por comas) para otros tipos, o ?type=all para cada modelo, primero chat, luego imagen, vídeo, música, voz y transcripción. Cada entrada tiene type (chat, image, video, music, speech, transcription), endpoints (las rutas que lo sirven) y pricing.
• Cada modelo de chat también indica lo que puede hacer: context_length, max_output_tokens, input_modalities (image = lee imágenes), supports_tools, supports_reasoning, supports_vision y supported_parameters (los campos de solicitud que acepta). Los mismos datos están también bajo los nombres de OpenRouter (architecture.input_modalities, top_provider.context_length, top_provider.max_completion_tokens, y pricing.prompt / pricing.completion en dólares por token), por lo que las herramientas creadas para la lista de OpenRouter leen la nuestra tal cual.
• GET https://api.uberllm.dev/v1/models/<model id>: un modelo, con su precio, su contexto (chat) y, para un modelo multimedia, parameters: un JSON Schema del cuerpo de la solicitud (consulta Crear un vídeo o imagen).
• Cada entrada, en ambas respuestas, también tiene:
  • available: true cuando una solicitud para él puede ser atendida ahora mismo. false significa que nadie lo está atendiendo en este momento, por lo que una solicitud sería rechazada con no_available_provider. Elige otro modelo o inténtalo de nuevo más tarde.
  • input_modalities: lo que el modelo acepta. Un modelo que necesita una imagen (imagen a vídeo, referencia a vídeo, edición de imágenes) lista "image" junto a "text"; uno que acepta un vídeo (upscaling) lista "video".
  • nsfw: true para un modelo creado para contenido adulto o sin filtrar (Lustify, los modelos "uncensored" y similares). Omite estos si tu producto debe permanecer seguro para el trabajo.
• Público, sin clave: GET https://api.uberllm.dev/api/v1/public/models (con precios, y los mismos campos available, input_modalities y nsfw)
• Web: uberllm.dev/#models, y una página por modelo en uberllm.dev/models/<model id>

Qué sucede en cada solicitud

1. UberLLM verifica que el modelo existe, que tu prompt se ajusta a su ventana de contexto, y que soporta herramientas si tu solicitud las utiliza.
2. Reserva el costo estimado de tu saldo y reenvía la solicitud.
3. La solicitud se envía a un proveedor disponible para ese modelo. El proveedor se elige de nuevo para cada llamada: el más barato que empieza a responder lo suficientemente rápido para el tamaño de tu prompt (dentro de 2x del más rápido medido, o en menos de 1 segundo). Un prompt largo en streaming también va a un segundo proveedor rápido cuando el primero tarda en empezar; recibes y pagas por una sola respuesta. Nombrar proveedores en provider.only, ignore o order, o configurar sort, reemplaza esta elección. Cómo funciona: smart routing.
4. Cuando la respuesta termina, UberLLM liquida al precio que el marketplace informa para esa llamada y libera el resto de la reserva.

Reintentos automáticos

Si una llamada falla antes de que te llegue cualquier contenido, UberLLM la reintenta por ti. El marketplace vuelve a emparejar un vendedor en cada intento, y no cobra nada por una llamada que falló antes de ser enrutada, por lo que un reintento solo te cuesta tiempo.

• Reintentado: ningún vendedor para el modelo en este momento (no_sellers_for_model, no_healthy_sellers), el marketplace se quedó sin tiempo para enrutar (route_deadline_exceeded), un 429 pidiendo esperar 5 segundos o menos, cualquier 5xx, un error de conexión, un vendedor cuya propia API key o cuenta falló, o ningún primer byte a tiempo.
• No reintentado: el modelo no existe, la solicitud es inválida, o un problema de billing o auth. Esos regresan de inmediato.
• Programación: hasta 4 intentos, esperando 0.3 s, 0.9 s, luego 2.7 s entre ellos (o el Retry-After que envió el marketplace, si es 5 segundos o menos). Cuando nadie está vendiendo el modelo, la respuesta regresa en pocos segundos.
• Esperando el primer byte: un stream obtiene 10 segundos (más para un prompt largo, y más para un modelo que suele ser lento); una respuesta sin "stream": true obtiene 85 segundos, porque nada llega hasta que está completa. Un intento que agota los 85 segundos completos no se espera una segunda vez. Ningún reintento comienza después de 150 segundos.

Una vez que el streaming ha comenzado, nada se reintenta: un fallo a mitad del stream termina el stream y solo se te factura por lo que se produjo.

Si cada intento falla, obtienes un error en lugar de una respuesta, y la reserva se libera por completo. Los más comunes:

Ver Errores para la lista completa.

Modelos de respaldo

Envía models con una lista de otros model ids para probar, en orden, cuando el primero no pueda ser servido:

{ "model": "deepseek/deepseek-v4-flash",
  "models": ["z-ai/glm-5.3", "qwen/qwen3.6-plus"],
  "messages": [{ "role": "user", "content": "hi" }] }

El siguiente modelo se intenta solo cuando nadie puede servir el anterior en este momento (no_available_provider), o nadie lo vende dentro de tu provider.max_price. Un error de solicitud (un body incorrecto, un model id desconocido en cualquiera de los campos) y una denegación de pago (saldo, límites de API key) se responden de inmediato y nunca se pasan a la lista. Como máximo 5 modelos en model y models juntos. El campo model de la respuesta y la fila de Actividad nombran el modelo que respondió. models funciona en /v1/chat/completions y en solicitudes de imagen, video, música y voz; /v1/messages y /v1/audio/transcriptions no lo leen.

Alias de modelos

En lugar de un ID de modelo, puedes nombrar lo que necesitas, y UberLLM elige el modelo en cada solicitud:

• best-price:<job>: el modelo disponible con el precio más bajo para una solicitud ordinaria. Un modelo de chat se compara por su precio por millón de tokens con la salida contada tres veces; un modelo de imagen por una imagen (una imagen de 1024×1024 cuando se valora por megapixel); un modelo de vídeo por su clip más corto; un modelo de música por una pista; un modelo de voz por 1K caracteres; un modelo de transcripción por un minuto.
• fastest:<job>: el modelo con el tiempo medio más bajo en sus solicitudes exitosas en UberLLM en los últimos 7 días (tiempo hasta el primer token para chat, tiempo hasta el archivo finalizado para medios), contando solo modelos con al menos 5 solicitudes de este tipo. Cuando ningún modelo tiene suficientes, la solicitud es rechazada con 503 no_timing_data, y best-price: sigue funcionando.

Ambos eligen solo entre modelos que están disponibles ahora mismo: el mercado en vivo muestra un vendedor saludable para ello, y la última solicitud de UberLLM al mismo en los últimos 10 minutos no encontró a todos los vendedores ocupados o caídos (la misma regla que available en /v1/models). En una ruta de medios, cuando el modelo que un alias eligió responde que nadie puede tomar la solicitud después de todo, la misma solicitud pasa al siguiente modelo que representa el alias (hasta 3 modelos), y el model de la respuesta nombra al que respondió. Cuando no hay ningún modelo disponible para el trabajo, la respuesta es 503 no_available_provider y no se cobra nada.

<job> es uno de chat, image, image-edit, text-to-video, image-to-video, music, speech, transcription. Envía un alias de chat a /v1/chat/completions o /v1/messages, y uno de medios a su ruta de medios. El campo model de la respuesta nombra el modelo al que se resolvió. GET /v1/models/aliases lista cada alias que se resuelve ahora mismo y su modelo; GET /v1/models/best-price:chat describe el modelo que representa, con alias configurado.

Opciones de enrutamiento

El objeto provider se lee en /v1/chat/completions. Una opción que UberLLM no puede aplicar es rechazada con 400 unsupported_routing_option y no se cobra nada, por lo que una solicitud nunca se ejecuta con una configuración descartada silenciosamente.

Los sufijos de modelo :floor y :nitro son aceptados y eliminados del ID del modelo; :floor ordena por precio y :nitro por throughput.

Para imagen, video, música y voz, cada solicitud se envía a un proveedor externo disponible para el modelo. provider.max_price es lo máximo que puede costar una unidad (imagen, segundo, megapixel, minuto, 1K caracteres o solicitud), como un número: { "max_price": 0.05 }; también limita la factura. Cualquier otra opción provider es rechazada para medios.

Etiquetas

Envía metadata, un objeto de hasta 16 valores de texto (claves de hasta 64 caracteres sin dos puntos, valores de hasta 512), en cualquier solicitud:

{ "model": "deepseek/deepseek-v4-flash", "messages": [...],
  "metadata": { "project": "spring-ads", "run": "42" } }

Las etiquetas se almacenan con la solicitud y nunca se envían a un proveedor. Aparecen en la solicitud en Panel de control → Actividad, en el estado de un trabajo de vídeo o música, y en la exportación CSV (columna metadata). Filtra Actividad por una etiqueta con GET /api/v1/usage/activity?tag=project:spring-ads (repite tag para requerir varias); el enlace CSV aplica el mismo filtro. En /v1/messages, el propio metadata ({"user_id": "…"}) de Anthropic se almacena de la misma manera.