Tiempo de ejecución del grupo de recursos

Úselo para investigar cuentas ocupadas, tiempos de reutilización o enrutamiento de conversaciones. Para ver por primera vez una llamada fallida, comience con uso diario.

SubLane realiza un seguimiento de los arrendamientos de solicitudes de modelo y los fallos transitorios de las cuentas en cada grupo que comparte una cuenta. El administrador puede inspeccionar el estado de la programación desde Cuentas, cambie un límite por cuenta a través de Configuración de programacióne inspeccionar todas las llamadas completadas en Administración → Todas las solicitudes. Cada usuario que ha iniciado sesión, incluido el administrador, tiene una cuenta personal. General → Solicitudes vista.

Admisión y afinidad

Las cuentas nuevas tienen de forma predeterminada 30 solicitudes de modelos simultáneas, configurables de 1 a 1000. Las actualizaciones conservan los límites de la cuenta guardada. Esta es la capacidad de la puerta de enlace local, no una garantía del proveedor. La capacidad del espacio de trabajo tiene por defecto 128 operaciones, incluidos camareros y lecturas de metadatos compartidos, y se puede configurar al inicio. La simultaneidad de miembros tiene un valor predeterminado de 10 y se puede establecer entre 0 y 1000; 0 elimina el límite de miembros. Los arrendamientos de cuentas permanecen retenidos hasta el cierre del cuerpo en los giros HTTP/SSE, compactación y WebSocket. Reducir un límite permite que finalicen las solicitudes existentes.

Una conversación inactiva o una conexión abierta WebSocket no consume ningún espacio de solicitud de modelo entre turnos. Una respuesta completa libera su ranura cuando el cuerpo se cierra. Después de la cancelación de un cliente, una transmisión Codex puede continuar leyendo durante hasta tres segundos para recopilar el uso final antes de liberar su espacio; la fecha límite total configurable de solicitud (30 minutos de forma predeterminada) y el cierre del proceso aún se aplican. Si el cliente deja una solicitud en ejecución sin enviar la cancelación, esa solicitud conserva su espacio hasta que finaliza o llega a la fecha límite de la solicitud.

Una conversación encuadernada lleva su cuenta. Un cambio iniciado por el cliente a un modelo diferente con un historial portátil completo puede seleccionar una cuenta de respaldo cuando la cuenta actual no puede atenderla; enrutamiento del modelo describe las restricciones de continuación. Los cambios de capacidad y salud por sí solos nunca mueven una vinculación. Cuando la capacidad está llena, una nueva solicitud espera hasta 30 segundos por defecto, con como máximo 100 solicitudes en espera por grupo de forma predeterminada. Un espacio de cuenta liberado o un límite de concurrencia aumentado despierta solicitudes en espera. Devuelve una cola llena HTTP 429 account_queue_full; vuelve una espera caducada HTTP 429 account_wait_timeout, ambos con Retry-After: 1. La espera y estos rechazos locales no interrumpen las transmisiones activas ni penalizan el estado de la cuenta ascendente.

Las solicitudes en espera cuentan para los límites de simultaneidad de miembros y admisión del espacio de trabajo y consumen la asignación de miembros RPM una vez. No reservan asignación ni consumen un espacio en la cuenta hasta que sean admitidos. El acceso al grupo, la política del modelo, la habilitación de miembros, la habilitación/revocación/vencimiento de claves, el estado de la cuenta, la cuota de suscripción y la asignación se verifican nuevamente antes del envío. La cancelación de clientes y el cierre del servicio eliminan rápidamente las solicitudes en espera. La espera libera el bloqueo de admisión y no retiene ninguna transacción de la base de datos; El uso completado se registra antes de que un espacio liberado esté disponible para otra solicitud.

El tiempo de reutilización regresa HTTP 429 account_cooling con un encabezado Retry-After limitado y no está en cola. Ninguna solicitud cambia automáticamente una conversación existente a otra cuenta. Una conversación nueva o sin sesión puede usar otra cuenta elegible inmediatamente; una conversación vinculada espera sólo su cuenta original. El agotamiento de la cuota de suscripción, los límites de miembros/espacios de trabajo y los errores de admisión de asignaciones mantienen sus guardias normales.

Sin Session_id o un no vacío prompt_cache_key, cada llamada obtiene una selección independiente y un ID de correlación ascendente aleatorio. No lee ni crea una entrada de afinidad. Las nuevas selecciones nativas rotan dentro de cada grupo entre las cuentas de suscripción elegibles que respaldan el modelo. Los prefijos heredados explícitos limitan la selección a su proveedor. Las conversaciones explícitas existentes sobre grupos predeterminados conservan su resumen histórico.

El límite cubre las solicitudes de modelos; La verificación de cuenta, el descubrimiento de modelos y las lecturas de cuotas permanecen sujetos a la política de admisión global existente y no consumen espacios de solicitud de modelo. Estas operaciones de metadatos no borran los tiempos de reutilización de solicitudes de modelo.

Ejemplo de vista de programación de cuenta y cuota de suscripción con valores sintéticos:

Enfriamiento y recuperación

El enfriamiento de toda la cuenta está reservado para las respuestas 429 ascendentes. Retry-After se respeta entre 1 y 3600 segundos; cuando está ausente o no es válido, el respaldo configurable tiene un valor predeterminado de 5 segundos. Los fallos en la actualización de credenciales tienen sus propios retrasos. Los plazos de solicitud, HTTP 408 y fallos de red desconocidos no enfrían toda la cuenta.

Explicit upstream 5xx responses and invalid/interrupted streams are counted for the selected account and model. El umbral predeterminado es tres fallos lógicos dentro de dos minutos, seguido de una refrigeración de 10 segundos modelo. Las fallas repetidas aumentan el retraso hasta cinco minutos. El umbral, ventana y duración inicial son configurables; un umbral de 0 deshabilitaciones modelo. Antigravity los límites de la tasa de modelos mantienen sus reglas de recuperación de alcance.

Antes de aceptar una respuesta previa exitosa, explícita HTTP 408, 500, 502, 503 y 504 rechazos pueden ser retrigados dos veces en la misma cuenta, con respaldo atado. Los registros vuelven a comprobar la membresía actual, clave, política de grupo/modelo, cuota, ciclo de vida de cuenta y reglas de contenido. Conservan un contrato de arrendamiento, solicitud de identificación, historial y liquidación final.

HTTP SSE emite los latidos de comentario cada 10 segundos mientras que el evento de la corriente continua. Un tiempo de salida de flujo opcional cuenta con los eventos de arriba; latidos cardíacos de aguas abajo no pueden ocultar un modelo estancado. Se desprende. Tiempo de entrada de la cabeza de la inferencia por defecto a cinco minutos, metadatos mantiene su tiempo de salida más corto, y el tiempo total de petición / vuelta predeterminado a 30 minutos. Configuración de despliegue.

Los administradores pueden limpiar las refrigeraciones sin habilitar una cuenta, renovar la autorización o restablecer la cuota de suscripción. Las conversaciones existentes mantienen su cuenta original. Las refrigeraciones de cuenta/modelo sobreviven al reiniciamiento. Actualización despeja las sanciones transitorias heredadas de toda la cuenta cuyo alcance de modelo era desconocido, preservando al mismo tiempo los límites de tarifa reales.

Refrigerio y recuperación creíble

Codex Las credenciales se refrescan a la demanda dentro de dos minutos de expiración. Si el refresco falla temporalmente, las solicitudes pueden continuar con el token de acceso existente sólo mientras que tiene más de 30 segundos restantes y no ha sido rechazado por el río arriba. El costo se revisa de nuevo después del intento de refresco. Claude y Antigravity mantener sus requisitos de validez existentes.

Los intentos de refresco fallidos comparten un retraso de reingreso específico de una cuenta: 30 segundos, un minuto, dos minutos, cuatro minutos, luego al menos cinco minutos. OAuth Retry-After se respeta, hasta una hora. Una vez que el retraso expira, la siguiente solicitud de modelo o lectura credencial puede volver a entrar; no hay un bucle de votación de fondo adicional. Otras cuentas conservan sus propios cronogramas de reingreso.

Si no hay restos de token utilizables, el modelo solicita el retorno 503 account_refresh_failed con Retry-After. Las fallas de retroceso no acumulan las penas de enfriamiento del modelo-call. El éxito de la actualización o la reautorización aclara el estado de la revitalización de la revitalización. Los retrasos de la retratamiento son locales de proceso, mientras que un rechazo de corriente se almacena con la credencial cifrada por lo que el reinicio no puede hacer que la señal sea elegible para el retroceso de nuevo.

El Codex token endpoint debe devolver un fracaso creíble explícito, como invalid_grant o refresh_token_reused, para requerir la reautorización. Un desconocido HTTP 400/401, respuesta proxy, o compartido OAuth El error de configuración del cliente por sí solo no marca una cuenta como necesidad de la reautorización. Un token refrescado que sigue siendo rechazado por el punto final del modelo sigue requiriendo la reautorización.

Selección de Quota-aware

Codex, Claude y Antigravity El tráfico de modelos comienza las actualizaciones compartidas de cuota de fondo para cuentas de el pool elegibles, sin esperar al proveedor IO. En la mayoría de las dos cuotas se ejecutan simultáneamente dentro de las ranuras de admisión del espacio de trabajo; duplicar las lecturas coalesce, y se aplican reglas de enfriamiento/backoff existentes. No hay un bucle de votación de ocio general. reconciliación y pausas. Claude las ventanas principales pueden excluir una cuenta agotada. Antigravity cheques sólo el modelo nativo requerido, con SDK sufijos de pensamiento normalizados; otros modelos siguen siendo elegibles y el estado de tiempo de ejecución de cuenta se mantiene disponible.

Para Codex y Claude, la selección lee la persistencia normalizada principal límite de suscripción en la misma transacción corta como política de pool y afinidad. Una negación explícita, una bandera de límite alcanzado, o una ventana al 100% utilizado excluye la cuenta de nueva selección sólo mientras la observación es fresca (dos minutos, acortada por un reset). Los datos de actualización no conocidos, actualizados por el futuro o ya activos no significa cuota cero.

Una conversación encuadernada cuya cuenta o solicitud Antigravity modelo se agota las devoluciones HTTP 403 quota_exhausted. El proveedor se revisa de nuevo después de la fecha límite de frescura/recomposición instantánea; llegar a ese tiempo no es una promesa que la prestación se ha recuperado. Nunca se mueve a otra cuenta. El rechazo de Quota no aumenta los fallos transitorios, y Borrar tiempo de reutilización no borra el cupo de suscripción. Las cuentas muestran un estado de programación de cuotas distintos.

Las filas de Quota llevan la revisión del ciclo de vida existente de la cuenta; deshabilitación/capacidad y reautorización invalidan las observaciones anteriores, y los escritos condicionales rechazan las refrescos más antiguos en vuelo. El esquema consolidado almacena metadatos de revisión del ciclo de vida con filas de cuotas y piden diagnóstico.

Registros recientes de peticiones

Los registros cubren los intentos de modelo autenticados que llegan a la programación de la puerta, incluyendo el rechazo de la capacidad de la cuenta/cooldown. HTTP fallas de validación de tipo de cuerpo/contenido, rechazo global de admisión, descubrimiento modelo, consultas de cuota y WebSocket prewarm no crear registros de llamadas modelo.

Los metadatos almacenados se limitan a los IDs de usuario/key/pool/account, proveedor, identificador de modelo consolidado, protocolo/operación, tiempo de inicio, duración, solicitud de correlación ID, latencia de primera salida nulable, resultado, código de error sanitario, corriente superior HTTP estado, y reportado / salida / cuenta de fichas de contacto. Los síntomas, los cuerpos de respuesta, los errores de proveedores brutos, encabezados, direcciones IP, identificadores de sesión y las credenciales no se registran. Los números de fichas perdidos permanecen nulos. Los condes describen respuestas individuales observadas; no están facturando o el libro de asignación de recursos. controles del equipo. Una corriente puede tener HTTP 200 aún terminan con un error, por lo que el resultado y el estado de corriente son distintos.

Los registros personales son filtrados por el usuario de sesión autenticado en SQL antes de la paginación; un ID de usuario suministrado por el cliente o el alcance no puede ampliar el acceso. API respuesta. Los usuarios pueden filtrar su propia historia por resultado, modelo exacto, API clave, solicitud de identificación y intervalo de tiempo, incluyendo llamadas a través de claves que posteriormente fueron revocadas. Los administradores pueden filtrar por separado por cuenta de miembro y suscripción. Las opciones de llamada derivan sólo de la historia retenida dentro del mismo ámbito de propiedad. Ambas opiniones están paginadas en lotes de 50. A la mayoría de 5.000 registros se retienen en una ventana de siete días.

Las tablas de solicitud personal y administrador muestran una tasa de impacto de caché de entrada al lado del recuento de caché: fichas de entrada caché divididas por tokens de entrada total, formateadas como porcentaje con la mayoría de un lugar decimal. Esto mide la parte de fichas de entrada servidos de la caché de arriba, no la parte de las solicitudes que afecten a una caché.

Cada nuevo intento de modelo recibe un servidor generado req_… Identificador, ignorando identificaciones suministradas por el callador. HTTP las respuestas lo devuelven X-Request-ID; WebSocket giros request_id para eventos creados/completos/incompletos y errores de gateway. El ID de respuesta de arriba es invariable. Los registros de antes de la actualización no tienen identificación de correlación o medición de primer rendimiento. La tabla de solicitud muestra un ID compacto debajo de cada hora de inicio con una acción de copia para el valor completo. Haga clic en el tiempo de inicio abre sus detalles con el ID completo.

first_token_ms mide el procesamiento de la puerta de entrada comienzan al primer texto normalizado no vacío, razonamiento, razonamiento-summario o el delta de la herramienta-argumento, incluyendo la programación y la espera de corriente. No es tiempo para el primer evento del ciclo de vida o la señal de cliente. La compactación, las corrientes sin un delta observado y los registros más antiguos se mantienen null; la UI lo llama Primera salida. La duración total todavía abarca el cierre del cuerpo.

Ejemplo de diagnóstico de solicitud personal con registros sintéticos:

API y almacenamiento

• GET /api/accounts/runtime: los recuentos actuales del estado de programación y la demanda de modelos.
• PATCH /api/accounts/{id}/limits: set max_concurrency (Integer 1–1.000).
• POST /api/accounts/{id}/resume: enfriamiento/failures explícitamente claros.
• GET /api/me/requests?cursor=0&outcome=: metadatos de solicitud del usuario actual, para cualquier función activada.
• GET /api/requests?cursor=0&account_id=&outcome=: administrador solicita metadatos; el resultado puede ser el éxito, incompleto, error, cancelado o rechazado.

Ambos puntos finales de la historia también aceptan model, request_id, key_id, from (inclusive Unix segundos) y until (Segundos Exclusivos Unix); el punto final del administrador acepta user_id. La retención sigue siendo de siete días, independientemente del rango solicitado. GET /api/me/requests/filters y sólo administrador GET /api/requests/filters devolver las opciones de llamada/llave atada sin identidad de suscripción o valores secretos.

Excepto los puntos finales de la historia personal explícitamente, estas rutas requieren una sesión de administrador habilitada; las mutaciones conservan el origen/JSON protecciones. El esquema consolidado crea tiempos de ejecución y tablas de historia del espacio de trabajo. credentials.key juntos antes de reemplazar una instalación de desarrollo.

Límites específicos para cada modelo

Explicit structured Antigravity Las respuestas tipo-limit se reducen sólo cuando el dominio de error, la razón y el modelo coinciden con la solicitud seleccionada. Las respuestas no conocidas 429 mantienen la refrigeración en toda la cuenta. Los límites modelo persisten en reiniciar y pertenecen al ciclo de vida actual de la cuenta; la reautorización, deshabilitación/enable y la limpieza manual invalidan el estado anterior.

Un modelo limitado regresa 429 model_cooling; el límite original del proveedor se reporta como 429 model_rate_limited. Ambos consejos de retry consolidados. Otros modelos siguen siendo utilizables, y las conversaciones existentes mantienen su unión de cuenta original. Después de la refrigeración, a la mayoría de una petición normal para ese modelo intenta recuperarse en un momento; no se envía ninguna sonda extra de inferencia. Los éxitos más antiguos o no relacionados no pueden borrar un límite más nuevo. Un intento de persistencia fallido mantiene la restricción en el proceso actual y se registra como un fallo de persistencia.

Las tarjetas de cuenta muestran un recuento de memoria limitada mientras que la programación general de las cuentas sigue disponible. Ajustes de programación → Desarrollamiento limpio despeja la cuenta y las refrigeraciones modelo, sin cambiar la habilitación, autorización o cuota de suscripción. HTTP 403. Se informa de que upstream_forbidden, en lugar de una solicitud de reautorizar.

Revisiones automáticas de aprobación de Codex

Las solicitudes codex-auto-review identificadas como guardian o review pueden usar metadatos coherentes del hilo padre para dar preferencia a la cuenta de la conversación principal, dentro del mismo usuario autenticado y grupo de recursos. Una vinculación existente de la sesión hija tiene prioridad. La cuenta debe superar las comprobaciones de compatibilidad, permisos, cuota, asignación de uso y capacidad. Si los datos del padre faltan, son contradictorios, ambiguos, caducados o no están disponibles, se vuelve a la selección normal sin modificar su vinculación. Los identificadores de sesión y caché del padre y de la revisión siguen separados. Las pruebas HTTP y WebSocket usan datos sintéticos; la aceptación por el cliente real de Codex sigue sin verificarse.

Distribuir conversaciones nuevas según cuota restante

SUBLANE_GATEWAY_QUOTA_WEIGHTED=true pondera por el porcentaje restante de la ventana más limitada. Solo entre candidatos prioritarios del mismo proveedor compatible con datos numéricos recientes y completos; Antigravity usa el modelo exacto. Datos desconocidos, antiguos, parciales o mezclados mantienen rotación uniforme.

Desactivado por defecto; requiere reinicio. Conversaciones vinculadas, preferencia de cuenta padre, permisos, asignaciones y concurrencia conservan prioridad. Los porcentajes son una heurística, no capacidades absolutas comparables entre planes.