Compte pool runtime

Utilisez ceci pour enquêter sur les comptes occupés, les cooldowns ou le routage de conversation. Pour un premier regard sur un appel échoué, commencez par Utilisation quotidienne.

SubLane suit les baux de modèles-demandes et les défaillances transitoires de compte dans chaque pool partageant un compte. L'administrateur peut inspecter l'état de programmation à partir Comptes, modifier une limite par compte par Paramètres de calendrier, et d'inspecter tous les appels complétés Administration → Toutes les demandes. Chaque utilisateur connecté, y compris l'administrateur, a une Généralités → Demandes vue.

Admission et affinité

Nouveaux comptes par défaut jusqu'à 30 requêtes de modèles simultanés, configurables de 1 à 1 000. Les mises à jour préservent les limites des comptes sauvegardés. Il s'agit d'une capacité de passerelle locale, et non d'une garantie du fournisseur. La capacité Workspace par défaut jusqu'à 128 opérations, y compris des serveurs et des lectures de métadonnées partagées, et peut être configurée au démarrage. HTTP/SSE, compactage et WebSocket La réduction d'une limite permet de terminer les requêtes existantes.

Une conversation inactive ou ouverte WebSocket connexion ne consomme pas de slot de demande de modèle entre les tours. Une réponse terminée libère son slot quand le corps ferme. Codex stream peut continuer à lire jusqu'à trois secondes pour collecter l'utilisation finale avant de libérer sa fente; la date limite de demande totale configurable (30 minutes par défaut) et le processus d'arrêt s'appliquent toujours. Si le client laisse une requête en cours sans envoyer d'annulation, cette demande conserve sa fente jusqu'à ce qu'elle se termine ou atteigne la date limite de demande.

Une conversation liée conserve son compte. Un changement initié par le client à un modèle différent avec l'historique portable complet peut sélectionner un compte support lorsque le compte courant ne peut pas le servir; routage du modèle Les changements de capacité et de santé ne peuvent à eux seuls avoir un effet contraignant. 30 secondes par défaut, avec au plus 100 demandes d'attente par pool par défaut. Un emplacement de compte libéré ou une limite de proximité accrue réveille les demandes d'attente. HTTP 429 account_queue_full; un retour d'attente expiré HTTP 429 account_wait_timeout, avec Retry-After: 1. L'attente et ces refus locaux n'interrompent pas les flux actifs ou pénalisent la santé des comptes en amont.

Les demandes d'attente comptent pour les limites d'admission des membres et de l'espace de travail et consomment le membre RPM Ils ne réservent pas d'allocation ou consomment un créneau de compte jusqu'à ce qu'il soit admis. L'accès au pool, la politique modèle, l'activation du membre, l'activation/révocation/expiration des clés, la santé du compte, le quota d'abonnement et l'allocation sont à nouveau vérifiés avant l'expédition. L'annulation du client et la fermeture du service suppriment les demandes d'attente rapidement.

Refroidissement des retours HTTP 429 account_cooling Aucune requête ne change automatiquement une conversation existante vers un autre compte. Une conversation sans session ou nouvelle peut utiliser un autre compte admissible immédiatement; une conversation liée n'attend que pour son compte original. L'épuisement du quota d'abonnement, les limites de l'espace de travail et les erreurs d'admission des membres conservent leurs gardes normaux.

Sans Session_id ou d'un produit non vide prompt_cache_key, chaque appel obtient une sélection indépendante et un ID de corrélation en amont aléatoire. Il ne lit pas ou ne crée pas d'entrée d'affinité. De nouvelles sélections natives tournent dans chaque pool parmi les comptes d'abonnement admissibles supportant le modèle. Préfixes d'héritage explicites limitent la sélection à leur fournisseur.

La limite couvre les demandes de modèles; la vérification des comptes, la découverte des modèles et la lecture des quotas demeurent limitées par la politique d'admission mondiale existante et ne consomment pas de créneaux de demande de modèles.

Exemple de programmation des comptes et de vue des quotas d'abonnement avec des valeurs synthétiques:

Refroidissement et récupération

Le refroidissement à l'échelle du compte est réservé à 429 réponses en amont. Retry-After est honoré dans un délai de 1 à 3600 secondes; en cas d'absence ou d'invalidité, le retour configurable par défaut à 5 secondes. HTTP 408 et des défaillances de réseau inconnues ne refroidissent pas l'ensemble du compte.

Le seuil par défaut est trois défaillances logiques en deux minutes, suivies d'un refroidissement du modèle de 10 secondes. Les défaillances répétées augmentent le délai jusqu'à cinq minutes. Le seuil, la fenêtre et la durée initiale sont configurables; un seuil de 0 désactive les refroidissements transitoires du modèle. D'autres modèles restent éligibles. Les demandes de récupération ordinaires réussies permettent de clarifier l'état applicable; les résultats tardifs ne permettent pas d'effacer les nouvelles défaillances. Antigravity les limites de taux du modèle conservent leurs règles de recouvrement.

Avant d'accepter une réponse en amont réussie, explicite HTTP 408, 500, 502, 503 et 504 les rejets peuvent être réévalués deux fois sur le même compte, avec un retour limité. Les requêtes revérifient l'adhésion actuelle, la clé, la politique de groupe/modèle, le quota, le cycle de vie du compte et les règles de contenu. Elles conservent un bail, demandent l'ID, l'historique et le règlement final. Des indices de réessayer en amont sont retournés au lieu de rejouer tôt. L'incertitude du réseau, 400/401/403/429, les flux acceptés et la sortie partielle ne sont pas automatiquement rejoués par ce mécanisme.

HTTP SSE Un timeout au ralenti du flux optionnel ne compte que les événements en amont; les battements en aval ne peuvent cacher un modèle décroché. Il est désactivé par défaut. L'en-tête d'inférence timeout par défaut est de cinq minutes, les métadonnées conservent son délai d'arrêt plus court et le total des temps d'exécution/demande par défaut est de 30 minutes. Voir configuration du déploiement.

Les administrateurs peuvent effacer les réductions de taux sans autoriser un compte, renouveler l'autorisation ou rétablir le quota d'abonnement. Les conversations existantes conservent leur compte original. Les réductions de taux de taux de change survivent au redémarrage.

Actualisation et récupération des titres de créance

Codex les pouvoirs sont rafraîchis sur demande dans les deux minutes suivant l'expiration. Si cette rafraîchissement échoue temporairement, les demandes peuvent continuer avec le jeton d'accès existant seulement s'il reste plus de 30 secondes et n'a pas été rejeté par l'amont. L'expiration est à nouveau vérifiée après la tentative de rafraîchissement. Claude et Antigravity conserver leurs exigences de validité existantes.

Les tentatives de rafraîchissement ont échoué et partagent un délai de réessayer spécifique au compte : 30 secondes, une minute, deux minutes, quatre minutes, puis au plus cinq minutes. OAuth Retry-After Une fois le délai expiré, la prochaine demande de lecture ou de modèle peut être réessayer; il n'y a pas de boucle de sondage de fond supplémentaire. D'autres comptes conservent leurs propres horaires de réessayer.

Si aucun jeton utilisable ne reste, le modèle demande le retour 503 account_refresh_failed avec Retry-After. Les échecs de rafraîchissement n'accumulent pas de pénalités de rafraîchissement d'appel de modèle. La rafraîchissement ou la réautorisation permet d'effacer l'état de rafraîchissement. Les retards de réessayer sont locaux-processus, tandis qu'un rejet en amont est stocké avec le justificatif crypté, de sorte que le redémarrage ne peut pas rendre ce jeton admissible à nouveau au retour.

Les Codex token endpoint doit renvoyer une défaillance de la qualification explicite, comme invalid_grant ou refresh_token_reused, pour exiger une réautorisation. Un inconnu HTTP 400/401, réponse par procuration, ou partagée OAuth L'erreur de configuration du client à elle seule n'indique pas qu'un compte a besoin d'une réautorisation. Un jeton rafraîchi qui est toujours rejeté par le paramètre modèle continue d'exiger une réautorisation.

Sélection des quotas

Codex, Claude et Antigravity Le trafic modèle commence à partager les mises à jour de quotas de fond pour les comptes de pool éligibles, sans attendre l'IO du fournisseur. Au plus deux lit quota exécuté simultanément dans les créneaux d'admission de l'espace de travail; le double lit coalesce, et les règles existantes de refroidissement/retour s'appliquent. Il n'y a pas de boucle de vote générale. réconciliation et pauses. Claude Les fenêtres principales peuvent exclure un compte épuisé. Antigravity ne vérifie que le modèle natif demandé exact, avec SDK Des suffixes de pensée sont normalisés; d'autres modèles restent éligibles et l'état d'exécution à l'échelle du compte reste disponible.

Pour Codex et Claude, sélection lit la normalisation persistante principale Un déni explicite, un drapeau de limite atteinte ou une fenêtre à 100% utilisée exclut le compte de la nouvelle sélection seulement lorsque l'observation est fraîche (deux minutes, raccourcie par une remise à zéro). Les données inconnues, inexistantes, futures ou déjà réinitialisées ne signifient pas qu'il y a un quota zéro. On ne suppose pas que d'autres limites nommées correspondent à des modèles et ne peuvent exclure un compte entier. Un quota faible mais positif ne modifie pas les poids de la bobine ronde. Un rafraîchissement échoué conserve la dernière observation réussie; il ne peut affecter l'horaire que jusqu'à la date limite de fraîcheur originale, jamais indéfiniment.

Une conversation liée dont le compte ou la demande Antigravity model est des retours épuisés HTTP 403 quota_exhausted. Le fournisseur est vérifié à nouveau après la date limite de fraîcheur/réinitialisation de l'instantané; atteindre ce temps n'est pas une promesse que l'allocation a récupéré. Il ne passe jamais à un autre compte. Effacer le refroidissement n'efface pas le quota d'abonnement. Les comptes indiquent un état de programmation distinct épuisé par quota.

Les observations réussies sont sauvegardées avant publication et survivent au redémarrage. Les lignes de quotas portent la révision du cycle de vie du compte existant; désactivent/enablent et réautorisent les observations antérieures, et les écritures conditionnelles rejettent les mises à jour plus anciennes en vol. Le schéma consolidé stocke les métadonnées de révision du cycle de vie avec les lignes de quotas et demande des diagnostics.

Comptes rendus des demandes récentes

Les enregistrements couvrent les tentatives de modèle authentifié qui atteignent le calendrier de passerelle, y compris la capacité de compte/refroidissement rejet. HTTP défaillances de validation de type corps/contenu, rejet d'admission à l'échelle mondiale, découverte de modèles, demandes de quotas, et WebSocket ne créent pas d'enregistrements d'appel de modèles.

Les métadonnées stockées sont limitées aux identifiants utilisateur/clé/pool/compte, fournisseur, identificateur de modèle limité, protocole/opération, heure de début, durée, code de corrélation de demande, latence de première sortie nulle, résultat, code d'erreur sanitisé, en amont HTTP les données d'entrée, de sortie, de comptage des jetons. Les données d'entrée, les données d'intervention, les erreurs brutes du fournisseur, les en-têtes, les adresses IP, les identifiants de session et les identifiants d'identification ne sont pas enregistrées. Les chiffres manquants restent nuls. Contrôles d'équipe. Un flux peut avoir HTTP 200 pourtant terminer avec une erreur, de sorte que le résultat et le statut en amont sont distincts.

Les enregistrements personnels sont filtrés par l'utilisateur de session authentifié dans SQL avant la pagination; un ID utilisateur fourni par le client ou la portée ne peut pas élargir l'accès. API réponse. Les utilisateurs peuvent filtrer leur propre historique par résultat, modèle exact, API Les options de l'appelant ne proviennent que de l'historique conservé dans la même portée de propriété. Les deux vues sont paginées en lots de 50. Au plus 5.000 enregistrements sont conservés dans une fenêtre de sept jours. Le nettoyage se déroule atomiquement lors de l'enregistrement et lors de la lecture de l'historique; les données inactives sont récupérées lors de la prochaine opération. Les identifiants d'enregistrement monotoniques ne sont pas réutilisés après le nettoyage de la conservation. Les noms de comptes supprimés rendent comme supprimés, sans supprimer les métadonnées historiques.

Les tableaux de requêtes personnels et d'administrateurs indiquent un taux de frappe de cache en entrée à côté du nombre de jetons en cache : jetons en cache divisés par des jetons en entrée totale, formatés en pourcentage avec au plus une décimale. Ceci mesure la part des jetons en entrée desservis à partir du cache en amont, et non la part des requêtes qui ont touché un cache. Un nombre de cache zéro signalé avec entrée positive indique 0 %; les nombres manquants, zéro entrée ou un nombre de cache dépassant le nombre total d'entrées indiquent un tiret em. Le taux est dérivé des métadonnées de requête existantes et n'ajoute aucune colonne stockée ou requête en amont.

Chaque nouvelle tentative de modèle reçoit un serveur req_… identifiant, ignorant les identifiants fournis par l'appelant. HTTP réponses retournez-le en X-Request-ID; WebSocket tours ajouter request_id L'identifiant de réponse en amont est inchangé. Les enregistrements avant la mise à niveau n'ont pas d'ID de corrélation ou de mesure de premier sortie. Le tableau de requête affiche un ID compact sous chaque heure de début avec une action de copie pour la valeur complète. Cliquer sur l'heure de début ouvre ses détails avec l'ID complet.

first_token_ms mesure le traitement de la passerelle commence par le premier texte normalisé non vide, raisonnement, résumé de raisonnement ou delta d'argument d'outil, y compris l'horaire et l'attente en amont. Il n'est pas temps pour le premier événement du cycle de vie ou jeton livré par le client. Compaction, flux sans delta observé et les anciens enregistrements garder nul; l'interface utilisateur l'appelle Première sortie. La durée totale couvre toujours la fermeture du corps.

Exemple de diagnostic de demande personnelle avec des dossiers synthétiques :

API et stockage

• GET /api/accounts/runtime: état de programmation actuel et nombre de demandes de modèles.
• PATCH /api/accounts/{id}/limits: ensemble max_concurrency (entier 1 à 1 000).
• POST /api/accounts/{id}/resume: un refroidissement/défaut explicitement clair.
• GET /api/me/requests?cursor=0&outcome=: l'utilisateur actuel demande des métadonnées, pour l'un ou l'autre rôle activé.
• GET /api/requests?cursor=0&account_id=&outcome=: l'administrateur demande des métadonnées; le résultat peut être réussi, incomplet, erreur, annulé ou rejeté.

Les deux paramètres historiques acceptent également model, request_id, key_id, from (y compris les secondes Unix) et until (exclusive Unix secondes); le paramètre administrateur accepte user_id. La rétention reste de sept jours, peu importe l'étendue demandée. GET /api/me/requests/filters et administrateur uniquement GET /api/requests/filters retourner les choix d'appelant/clé limités sans identité d'abonnement ni valeurs secrètes.

À l'exception des paramètres d'historique explicitement personnels, ces itinéraires nécessitent une session d'administrateur activée; les mutations conservent l'origine/JSON protections. Le schéma consolidé crée des tables d'exécution et des tables d'historique de l'espace de travail. credentials.key ensemble avant de remplacer une installation de développement.

Limites spécifiques au modèle

Structuration explicite Antigravity Les réponses à la limite de vitesse ne sont réduites que lorsque le domaine d'erreur, la raison et le modèle correspondent à la requête sélectionnée. Les réponses inconnues 429 conservent le refroidissement à l'échelle du compte. Les limites du modèle persistent à travers le redémarrage et appartiennent au cycle de vie du compte courant; la réautorisation, la désactivation/activation et la suppression manuelle du refroidissement invalident l'état antérieur.

Un modèle limité renvoie 429 model_cooling; la limite initiale du fournisseur est déclarée comme 429 model_rate_limited. Les deux préservent des retrys limités. D'autres modèles restent utilisables, et les conversations existantes conservent leur lien de compte original. Après le refroidissement, au plus une demande normale pour que le modèle tente la récupération à la fois; aucune sonde d'inférence supplémentaire n'est envoyée. Les succès plus anciens ou non liés ne peuvent effacer une limite plus récente.

Les cartes de compte affichent un nombre limité de modèles, tandis que le calendrier global des comptes reste disponible. Paramètres de calendrier → Effacer le cooldown permet de supprimer les comptes et les modèles de refroidissement, sans modifier l'activation, l'autorisation ou le quota d'abonnement. HTTP 403 est déclaré comme upstream_forbidden, plutôt qu'une demande de réautorisation.

Revues d’approbation automatiques de Codex

Les requêtes codex-auto-review identifiées comme guardian ou review peuvent utiliser des métadonnées cohérentes du fil parent pour privilégier le compte de la conversation principale, au sein du même utilisateur authentifié et du même groupe de ressources. Une association existante de la session enfant reste prioritaire. Le compte doit satisfaire les contrôles de compatibilité, de permissions, de quota, d’allocation d’usage et de capacité. Si le parent est absent, contradictoire, ambigu, expiré ou indisponible, la sélection normale reprend sans modifier son association. Les identifiants de session et de cache du parent et de la revue restent distincts. Les tests HTTP et WebSocket utilisent des données synthétiques ; l’acceptation par un véritable client Codex reste à vérifier.

Répartir les nouvelles conversations selon le quota restant

SUBLANE_GATEWAY_QUOTA_WEIGHTED=true pondère selon le pourcentage restant de la fenêtre la plus contrainte. Uniquement si tous les candidats prioritaires ont des données numériques fraîches et complètes du même fournisseur pris en charge ; Antigravity utilise le modèle exact. Sinon, rotation égale.

Désactivé par défaut ; redémarrage requis. Les conversations liées, préférences du compte parent, permissions, allocations et contrôles de concurrence restent prioritaires. Les pourcentages sont une heuristique, pas des capacités absolues comparables entre offres.