responses efficiency iteration

Itération d’efficacité du chemin Responses

Historical report: measurements and conclusions describe the original dated investigation, not current performance guarantees.

Date : 30 juillet 2026

Résultat

Cette itération réduit le temps de préparation des requêtes lorsqu’un snapshot d’usage existe mais a dépassé son TTL.

Auparavant, la requête modèle attendait le rafraîchissement d’usage de tous les comptes actifs. Désormais :

• le premier snapshot reste bloquant ;
• un snapshot périmé est servi pendant son actualisation en arrière-plan ;
• un snapshot vieux de plus de trente minutes redevient bloquant ;
• les actualisations concurrentes d’un même compte sont fusionnées ;
• la tâche d’arrière-plan travaille sur une copie et ne persiste que le champ usage, afin de ne pas écraser une modification administrative récente ;
• un compte ayant un reset hebdomadaire programmé conserve un rafraîchissement bloquant, car sa valeur d’usage peut déclencher la consommation du crédit ;
• USAGE_STALE_WHILE_REVALIDATE=false restaure le comportement antérieur.

La borne de trente minutes est configurable avec USAGE_STALE_MAX_AGE_MS.

Benchmark local

Le script scripts/benchmark-usage-refresh.mjs compare la préparation historique et la préparation candidate avec quatre comptes et des sondes simulées de 50 ms.

Sur vingt paires :

Variante	Médiane	p95
Baseline bloquante	52,10 ms	52,14 ms
Candidate stale-while-revalidate	0,04 ms	0,07 ms

L’amélioration médiane de la phase de préparation est de 99,91 % dans ce test isolé. Ce résultat ne mesure pas la latence du modèle ou du réseau upstream.

Le benchmark réel sur une copie du store distant n’a pas été rejoué pendant cette itération : l’hôte privé était inaccessible depuis la machine de développement (Network is unreachable). Aucune tentative n’a modifié la production.

Instrumentation ajoutée

Les traces exposent désormais :

• latencyBreakdown.preparationMs ;
• latencyBreakdown.upstreamHeadersMs ;
• usageRefresh.background, blocking et shared ;
• tokensInputCacheWrite ;
• tokensReasoning ;
• inputContext.compactionItemCount ;
• inputContext.itemsBeforeLatestCompaction.

Les deux compteurs de compaction permettent de détecter des préfixes potentiellement superflus sans persister le contenu des requêtes.

L’estimation de coût distingue aussi les écritures de cache GPT-5.6 des lectures et des entrées ordinaires. Une écriture est comptée au tarif officiel de 1,25 fois l’entrée non cachée, sans recompter les mêmes tokens dans les entrées ordinaires.

Tokens : décision conservatrice

Cette itération n’effectue aucune suppression automatique de contexte.

La documentation OpenAI autorise à supprimer l’ancien préfixe après une compaction serveur stateless, mais exige de transmettre intacte la fenêtre canonique renvoyée par /responses/compact. Le proxy ne peut pas distinguer ces deux origines à partir d’un élément type: "compaction" seul. Un pruning automatique risquerait donc de supprimer un élément conservé par le compactage standalone.

Les nouvelles traces permettront de mesurer la fréquence de ces formes avant de définir un contrat explicite et dépendant du fournisseur.

Reproduction

node --import tsx scripts/benchmark-usage-refresh.mjs \
  --samples 20 \
  --accounts 4 \
  --delay-ms 50

Référence officielle :

• Compaction

L'analyse suivante des breakpoints explicites GPT-5.6 est documentée dans prompt-cache-breakpoint-audit.md. Les traces locales montrent que le cache implicite est déjà très efficace ; aucun breakpoint automatique n'a donc été ajouté sans A/B upstream.

L'itération suivante supprime l'attente d'un catalogue de modèles expiré du chemin critique des requêtes. Elle est documentée dans model-catalog-latency-iteration.md.

L'itération suivante réduit à un scan sans allocation la détection d'images des longues requêtes textuelles. Elle est documentée dans image-detection-latency-iteration.md.

L'itération suivante supprime la préparation asynchrone et les mutations du store pour les comptes dont le token et l'usage sont déjà frais. Elle est documentée dans account-preparation-latency-iteration.md.

L'itération suivante remplace la réécriture de la fenêtre des traces à chaque fin de stream par un journal append-only compacté périodiquement. Elle est documentée dans trace-completion-latency-iteration.md.

L'itération suivante supprime les backoffs sur le même compte après un rate limit afin de rendre la rotation immédiatement effective. Elle est documentée dans upstream-retry-policy-iteration.md.

L'itération suivante couvre également les rate limits renvoyés sous forme SSE, qui étaient auparavant relayés avant la rotation. Elle est documentée dans stream-rate-limit-rotation-iteration.md.

L'itération suivante évite les parses JSON inutiles sur les deltas SSE tout en conservant les diagnostics et l'usage. Elle est documentée dans sse-diagnostics-latency-iteration.md.

---

Migrated from docs/responses-efficiency-iteration.md on 2026-09-07.