Limites

Comment lire cette page

AI — limites par requête

/api/ai/generate et /api/ai/stream utilisent la même policy de validation.

Les variables de policy correspondantes sont lues depuis l’environnement et utilisent ces valeurs uniquement comme defaults.

AI — defaults de policy

dailyRequests: 30
dailyOutputTokens: 50000
maxOutputTokensPerRequest: 1024
maxMessagesPerRequest: 30
maxCharactersPerRequest: 60000
premiumBoostsOnSignup: 10

AI — pièces jointes

Types actuellement acceptés : PDF, PNG, JPEG, WEBP et GIF.

AI — budget provider quotidien

OrbitWake possède une limite serveur optionnelle ORBITWAKE_AI_HARD_DAILY_BUDGET_USD.

Si cette valeur est absente, invalide ou égale à 0, le hard budget est désactivé. Si elle est positive, les routes AI et IDE vérifient le coût provider cumulé du jour avant de lancer la génération.

La valeur effective de production n’est pas publiée dans cette documentation.

AI — timeout provider

Les providers OpenAI, Anthropic et OpenAI-compatible inspectés utilisent actuellement un timeout de 90 secondes par appel provider.

OrbitWake Auto peut tenter un fallback provider lorsqu’une erreur est retryable et qu’aucun texte n’a encore été streamé. Le temps total d’une requête peut donc être différent du timeout d’un seul appel provider.

Projects — limites de private beta

Les limites principales sont stockées par workspace dans private_beta_access.

Le schéma de migration définit les defaults suivants :

Ces valeurs peuvent être différentes pour un workspace donné.

Projects — champs et fichiers

Memory — tailles et résultats

Memory — capture explicite

Une mémoire capturée depuis une phrase de type “remember…” n’est acceptée par l’extracteur actuel que si le contenu extrait ne dépasse pas 4 000 caractères.

Le titre automatique est réduit à environ 88 caractères pour l’affichage, tandis que la colonne et l’API autorisent jusqu’à 160 caractères.

Connectors

Les limites d’entrée propres à une action Connector dépendent du connecteur et de l’action ; il n’existe pas un plafond global unique documenté pour tous les inputs Connector.

IDE — pairing et session

IDE — Ask

IDE — Agent

IDE — backend vs extension locale

Le backend Agent accepte jusqu’à 12 fichiers, mais l’extension VS Code actuelle sélectionne localement un maximum plus bas avant l’envoi. Les limites client peuvent donc être plus strictes que les limites de l’endpoint.

Documenter une capacité backend ne signifie pas que tous les clients officiels l’utilisent au maximum.

Domains — rate limits

Le endpoint retourne les headers X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset. Sur refus, Retry-After est aussi présent.

Le rate limiter actuel est maintenu en mémoire du process Node ; cette implémentation n’est pas un quota distribué universel pour toute l’API.

Auth — durées utiles

Ce qui n’est pas une limite globale

• les 30 recherches domaine / 10 minutes ne s’appliquent pas aux autres endpoints ;
• le cap de 100 activités Connector ne limite pas le nombre total d’événements stockés, seulement la lecture retournée ;
• les 8 memories pertinentes ne limitent pas le nombre total de memories enregistrées ;
• les 12 fichiers IDE Agent sont une limite du endpoint Agent, pas de Projects ;
• les defaults private beta peuvent être modifiés par workspace ;
• les defaults AI de policy peuvent être remplacés par l’environnement.

Valeurs déclarées dont l’enforcement n’est pas vérifié ici

Deux exemples importants :

• dailyRequests et dailyOutputTokens existent dans freeAiPolicy(), mais les handlers AI inspectés utilisent directement les limites par requête et le hard provider budget, sans enforcement journalier visible dans ces chemins ;
• maxBuildsPerHour existe dans private_beta_access et dans le status beta, mais l’enforcement n’apparaît pas dans les opérations Projects inspectées.

La documentation ne les présente donc pas comme quotas effectivement bloquants tant qu’un chemin d’enforcement n’est pas vérifié.

Limites susceptibles d’évoluer

Les limites configurables peuvent changer sans modification du client. Les limites fixes peuvent évoluer avec une nouvelle version du runtime.

Comme OrbitWake ne publie pas encore une API v1 stable, un consommateur externe ne doit pas considérer ces valeurs comme engagement contractuel permanent.

Conseils côté client

• validez la taille du payload avant l’envoi ;
• respectez Retry-After lorsqu’il est fourni ;
• traitez 413 comme signal de réduction du payload, pas comme erreur transitoire ;
• ne codez pas en dur un quota configurable comme si sa valeur était permanente ;
• pour Projects beta, utilisez les limites retournées au workspace lorsque cette surface les expose.

Résumé des limites les plus structurantes

Suite de la documentation

La section API est maintenant documentée de bout en bout : vue d’ensemble, authentification, requêtes, réponses, streaming, erreurs et limites.