Documentación de HopBaseConcurrencia, tiempos de espera y facturación
Límites de concurrencia de HopBase, comportamiento de los tiempos de espera por endpoint y valores recomendados en el cliente, límite de tamaño de la petición y cuándo se factura exactamente.
Esta página reúne las reglas de funcionamiento que conviene conocer antes de integrar. Para códigos de error y política de reintentos, consulta Códigos de error y reintentos.
Concurrencia
- Una cuenta ejecuta 5 peticiones a la vez por defecto. Una clave puede tener su propio límite, menor; se aplica el más bajo de los dos.
- El chat, la generación de imágenes, el envío de vídeo y
/v1/messages/count_tokensconsumen concurrencia. Las subtareas de los asistentes de programación, los scripts por lotes y varios clientes abiertos llenan el cupo enseguida. - Al superarlo recibes un 429 con
User concurrency limit reached (N)oAPI key concurrency limit reached (N), junto conRetry-After. - Escríbenos para ampliar el límite.
Cuando el cupo está lleno se rechaza, no se encola
Las peticiones que superan el límite se rechazan de inmediato con un 429; nada espera en el servidor. Limita el ritmo en tu cliente o reintenta según Retry-After.
Tiempos de espera
| Caso | Comportamiento del servicio | Tiempo de lectura recomendado en el cliente |
|---|---|---|
| Chat en planes Gemini de conexión directa | Una generación que no termina en unos 100 segundos se considera agotada y se reintenta en otra cuenta, así que la espera total puede ser mayor | 240 s o más |
| Chat sin streaming en el resto de plataformas | Sin límite fijo; con contextos grandes el primer token puede tardar más de un minuto | 300 s o más |
| Generación de imágenes síncrona | Las imágenes grandes suelen tardar entre 30 y 100 segundos | 300 s o más |
| Imágenes asíncronas y vídeo | El envío responde de inmediato; el resultado se obtiene por sondeo | 60 s bastan para el envío |
Usa streaming para salidas largas y los endpoints asíncronos para trabajos largos: así evitas casi todos los problemas de tiempo de espera.
Tamaño de la petición
El cuerpo de una petición está limitado a 60 MB; por encima se devuelve 413. Las imágenes y los vídeos en base64 lo alcanzan rápido, así que compáctalos o envía una URL cuando el modelo lo admita.
Facturación
| Situación | ¿Se factura? |
|---|---|
| Petición correcta | Sí, según la unidad del modelo (tokens / imagen / segundo) |
| Petición fallida (4xx, 5xx) | No |
| Flujo interrumpido a mitad, o cliente desconectado antes de tiempo | Sí, por lo ya generado |
| Tarea asíncrona fallida | No |
Además:
- Sin saldo se bloquean las peticiones nuevas: cuando el saldo disponible llega a cero, las peticiones nuevas devuelven 402. Las que ya están en curso no se ven afectadas.
- Los envíos de vídeo reservan saldo: se reserva el coste estimado, de modo que un saldo positivo puede devolver 402 si «reservado en curso + esta estimación» lo supera. La reserva se libera al terminar la tarea.
- Cuotas por clave: si una clave tiene cuota propia, agotarla devuelve 402 con
budget_exceeded.
Consultar saldo y consumo
curl https://api.hop-base.com/v1/usage \
-H "Authorization: Bearer sk-tu-clave"La respuesta trae balance (saldo disponible), unit (moneda, USD) y un objeto quota con la cuota y el consumo de esa clave. Para el detalle, abre Consumo en la consola.
Los enlaces de resultado de imágenes y vídeo caducan en plazos distintos: consulta API de generación de imágenes y Generación de vídeo.
Base URLs y protocolos
Elija la URL compatible con OpenAI o Anthropic de HopBase para cada modelo y cliente.
Códigos de error y reintentos
Estructura de las respuestas de error de HopBase, qué significa cada código de estado y si se puede reintentar, cómo se manifiestan los fallos en streaming y qué datos incluir al reportar un problema.