coder : efficacité de coût 5.66× sur fable 5 & qualité SWE

1 · Efficacité de coût : deux leviers indépendants

coder réduit le coût facturé par deux mécanismes distincts, et cette page maintient leur comptabilité séparée : la compression (mesurée) et les paliers saver (un fait tarifaire). Chaque levier a sa propre formule, ses propres preuves et sa propre ligne dans la table de méthodologie.

1.1 · Compression (mesurée)

Le pipeline fournit au modèle une représentation compacte de la même session. Par requête, le registre enregistre la base non compressée et l'entrée réellement envoyée : facteur = base ÷ envoyé. Médiane 2.83× (p10–p90 2.26–3.08×) sur la dernière fenêtre complète de registre (2026-07-23, n = 7,222 requêtes).

Preuve de qualité pour ce levier : l'A/B SWE / SWE Pro compression ON vs OFF (§2) — tâches identiques, notation Docker officielle, pipeline activé versus désactivé — constitue la preuve de qualité de cette compression : les issues de résolution suivent le bras non compressé au bruit près. La formule et la fenêtre d'échantillonnage du 2.83× lui-même figurent dans la table de méthodologie ; ce paragraphe ne concerne que le levier de compression — le saver a sa propre section ci-dessous.

💰 #.#x = taux d'économies — l'indicateur de la barre d'état en bas à gauche de cet enregistrement d'écran non retouché est le multiple d'économies de compression en direct : il démarre au plancher de 2.0× et monte à 5.1× en fin de run (pic à 6.1×) à mesure que le contexte mis en cache/compressé s'accumule — 92.4% de part d'entrée en cache sur l'ensemble du run, selon le registre rollout de la session (12 entrées d'usage API, 287,269 tokens d'entrée). La tâche est une vraie tâche SWE publique sur pallets/flask (fonctionnalité CLI + tests, tous au vert). La lecture est accélérée 8× (annoté en haut à droite) ; contenu intact.

1.1b · Fenêtre de contexte effective (même mesure, second dividende)

La compression a un second effet au-delà du coût : la fenêtre de contexte physique du modèle contient la représentation compressée, sa capacité effective est donc multipliée par le même facteur mesuré. À la médiane mesurée de 2.83× (p10–p90 2.26–3.08×), une fenêtre physique de 200K tokens porte environ 450K–620K tokens de contenu de session (200K × 2.26–3.08). Conséquence pratique : les sessions longues subissent rarement la pression de la fenêtre de contexte — moins de compaction, moins de contexte perdu, un travail de longue durée stable.

• Ligne de conversion : capacité effective = fenêtre physique × facteur de compression mesuré. Même source de données que le §1.1 ; aucune mesure séparée.
• Exemple réel du même jour de registre : une session du 2026-07-23 a accumulé 58,815,232 tokens d'entrée qui auraient été envoyés, livrés en 18,622,941 tokens réellement envoyés (3.16×) — une journée de trafic de contexte portée à environ un tiers de sa taille brute (registre de session rollout-2026-07-23T09-27-46-019f8fcd….jsonl, cumul imgctxOriginalInputTokens vs envoyé).

1.2 · Paliers saver (fait tarifaire)

Indépendamment du levier de compression mesuré ci-dessus, coder propose deux voies de livraison à moitié prix. Formule : facturé = 50% × prix de la voie standard — un fait de grille tarifaire qui n'exige aucune preuve de test. Il n'entre dans le facteur vedette que comme facteur tarifé officiel (50% du catalogue ⇒ 2.00×) et n'est jamais mélangé au chiffre de compression mesuré lui-même :

• batch — soumission-récupération asynchrone pour les charges non interactives (évaluation en masse, analyse en arrière-plan, jobs planifiés) : 50% du coût standard.
• flex — la même interface de streaming synchrone, planifiée sur capacité flexible, pour le travail qui n'exige pas une livraison à capacité réservée : 50% du coût standard.
• Mêmes modèles, même qualité, même sortie — les paliers changent l'ordonnancement, pas les résultats.
• Comptabilité du facteur vedette : facteur vedette = compression (médiane mesurée 2.83×) × saver (tarification officielle 2.00×) = 5.66×. Le terme saver provient de la grille tarifaire officielle (batch/flex à 50% du catalogue ⇒ 2.00×), pas du trafic de cette fenêtre — la fenêtre vedette 2026-07-23 elle-même n'a porté aucun trafic saver, raison précise pour laquelle ce terme est tarifé et non pondéré par le trafic.

Compression pure à l'échelle de la flotte (contre-vérification prudente)

Les chiffres ci-dessus proviennent des registres d'une seule machine. En contre-vérification à l'échelle de la flotte, nous avons mesuré la compression de tokens pure uniquement sur 7 jours de trafic gateway réel :

2 · SWE / SWE Pro : compression ON vs OFF

Le pipeline d'efficacité ne mérite d'être livré que s'il préserve la qualité de sortie. Nous avons exécuté les suites SWE-bench, standard du secteur, en A/B interne — tâches identiques, modèles identiques, harnais de notation Docker officiel, pipeline ON (compressé) versus OFF (direct) — les deux suites rejouées sur le même build courant du pipeline.

Notes de protocole : échantillons d'instances fixes (Lite 10 / Pro 18 paires) ; les deux bras d'une paire exécutent la même instance, le même modèle, le même lot. Les verdicts proviennent des seuls harnais Docker officiels (Lite : swebench run_evaluation sur princeton-nlp/SWE-bench_Lite ; Pro : SWE-bench_Pro-os, jefzda/sweap-images) — aucun jugement par LLM. « Accord » = tâches où les deux bras ont atteint le même verdict résolu/non résolu. Pipeline verrouillé à origin/main 8a9175d pour les deux reruns.

L'unique tâche Pro divergente, navidrome-0488, a été tranchée par un rerun d'équivalence dédié à N=5 par bras : ON 3/5 vs OFF 3/5 — les deux bras sont équivalents au bruit près (test exact de Fisher p = 1.0). Tous les verdicts proviennent du harnais Docker officiel (10/10 runs notés, rc = 0), et les 10 fenêtres de run montrent collapsed_turns = 0 avec zéro réécriture, c.-à-d. que le chemin de compression a laissé les transcriptions intactes. Comptabilité de la variance : les 4 runs échoués se répartissent ON 2 + OFF 2 et partagent le même schéma d'erreur propre au modèle — le bras non compressé tombe dans les mêmes pièges. Verdict : la divergence d'origine est de la variance agentique run à run, pas un dommage de compression (rapport de verdict N=5). Note de périmètre : N = 5 par bras sur une seule instance, même protocole et même instance que le §2, pipeline 8a9175d — une lecture d'équivalence à petit N, pas une affirmation universelle.

• SWE-bench Lite (n=10 paires, rerun sur le pipeline courant) : ON 10/10 vs OFF 10/10, accord 10/10 — zéro instance divergente ; chaque paire résolue à l'identique dans les deux bras. Lite penche vers le facile, cette suite mesure donc la parité à difficulté égale, pas la supériorité.
• SWE-bench Pro (n=18 paires, rerun sur le pipeline courant) : ON 15/18 vs OFF 16/18 ; verdicts en accord sur 17 des 18 tâches. L'unique tâche divergente est tranchée ci-dessus (rerun d'équivalence N=5 sur navidrome-0488 : ON 3/5 vs OFF 3/5, Fisher p = 1.0, verdict de variance agentique).
• Alignement des échecs (Pro) : hormis l'unique tâche divergente, chaque échec Pro a échoué dans les deux bras (ansible, une instance element-web).
• Fidélité de contexte : 98/98 sondes de rappel/état avec réponse correctes dans les deux bras, et 0/16 réponses fabriquées sur les sondes délibérément sans réponse dans les deux bras.

3 · Méthodologie : d'où vient chaque nombre

Notre règle pour cette page : un nombre n'apparaît que s'il peut être tracé jusqu'à un enregistrement écrit par machine ou un script reproductible. Formules et fenêtres d'échantillonnage ci-dessous.

Limites connues (énoncées, pas cachées)

• Le terme de compression du facteur vedette (2.83×) est mesuré sur les registres de session d'une seule machine de build — le terme saver (2.00×) est un fait tarifaire, pas une mesure ; la contre-vérification à l'échelle de la flotte rapporte la compression pure à l'échelle de la flotte.
• Les échantillons de benchmark sont petits (10 + 18 paires ; le rerun d'équivalence est à N=5 par bras sur une seule instance). Nous rapportons la parité, l'accord et l'équivalence au bruit près, pas la supériorité.
• Le compte tarifaire de première ligne mélange la part d'entrée en cache d'une seule machine sur une seule journée (94.9%) avec les prix catalogue officiels ; les primes d'écriture de cache sont exclues du mélange et signalées comme telles. Les chiffres de prix effectif relèvent de l'arithmétique d'un compte mesuré, pas d'un devis de facturation.
• Les montants en dollars par run entre bras incluent la variance du nombre de tours et ne sont délibérément pas utilisés comme preuve de compression où que ce soit sur cette page.
• La matrice de fidélité de contexte porte sur un modèle, une graine, un jour (98 sondes avec réponse par bras).
• Les conversions de devises dans les registres utilisent une référence FX estimée (frankfurter, 2026-06-30), pas le FX de facturation.