Model stack Chapitre 16 / 42

Brancher Opus, GLM, Kimi, Grok & DeepSeek

L'usine recrute ses équipes : un roster tout jugement et un roster tout poids publiés se posent à côté du roster de production — validés par la jauge avant de coûter un centime.

Hier, vous avez posé la clé de la passerelle : un compte, tous les moteurs, et la promesse qu’un nouveau modèle ne coûterait plus qu’une ligne de YAML. Mais regardez votre usine ce matin : elle tourne toujours sur les quatre moteurs choisis au chapitre 13, alors que le registre en compte des centaines. À la fin de ce chapitre, vous aurez encaissé la promesse : deux rosters complets de plus dans adws/adw_config/, un roster frontier où chaque siège de jugement paie le meilleur moteur du jour, et un roster open weights entièrement sur poids publiés, chacun validé par la jauge du chapitre 14 avant de coûter un centime. Vous saurez aussi lire le marché : pourquoi Opus 5 a le même prix sur toutes ses routes quand GLM 5.3 en a vingt qui se battent, et pourquoi « frontier » est un étage de lecture, pas une étiquette officielle.

Les frontier : Opus et consorts

L’idée en une phrase

Un modèle frontier est un moteur du haut de l’étage : le jugement le plus cher et le plus fiable du marché, réservé aux sièges du roster où une décision se prend. La pièce du jour, frontier.config.yaml, vit entièrement côté code déterministe : un fichier de plus à côté du roster de production, aucune couture déplacée.

Points clés

  • Frontier est un étage, pas une marque. La jauge du chapitre 14 classe par prix d’entrée (seuil à 3 $/M). Le jugement, lui, se mesure sur vos propres ADW, ce sera le travail du chapitre 17. Les deux lectures ne coïncident pas toujours, et c’est instructif.
  • Un modèle fermé a un tarif, pas un marché. Au relevé du 1er septembre 2026, anthropic/claude-opus-5 s’affiche à ~5 $/M en entrée, ~25 $/M en sortie sur toutes ses routes : l’éditeur fixe le prix, les routes sont ses partenaires d’infrastructure. Comparez avec les open weights du second sous-thème : vingt routes, vingt prix.
  • Le haut de l’étage bouge vite, et parfois vers le bas. x-ai/grok-4.6, frontier par la capacité, s’affiche à ~2 $/M en entrée, ~6 $/M en sortie, sous le seuil de la jauge. Détail à connaître : son tarif double au-delà de 200 000 tokens de prompt. Le prix d’un moteur peut dépendre de la taille du contexte que vous lui donnez.
  • Le cache d’entrée est le levier caché des frontier. La relecture de cache d’Opus 5 se facture ~0,50 $/M, un facteur 10 sous son prix d’entrée. Un runner qui poursuit la même session (chapitre 13, la reprise en session vivante) en profite mécaniquement.
  • Le jugement ne se paie que là où il décide. Dans le roster frontier, Opus prend le plan et la revue, la reconnaissance descend d’un cran. Payer du frontier sur une voie mécanique n’achète rien, vous le chiffrerez au chapitre 17.

Exemple concret

Reprenez le SDLC du chapitre 13 et imaginez-le sur le roster frontier : le planner et le reviewer passent sur Opus 5 (~5/25 $/M, réflexion haute), le builder sur un moteur à 1 M de contexte (~3/15 $/M), le scout sur Grok 4.6 (~2/6 $/M). Même graphe, mêmes phases, mêmes gates : seuls les moteurs changent. L’ordre de grandeur : quelques dollars le run là où le roster du chapitre 13 tenait en ~40 à 60 centimes, soit un facteur 5 environ, presque entièrement concentré sur les sièges de jugement. C’est un choix d’arbitrage, pas un progrès automatique : vous le réservez aux demandes où un plan raté coûte plus cher que le roster, et le chapitre 25 lancera les deux en parallèle pour les départager sur pièces.

Les frontier au relevé du 1er septembre 2026

Moteur$/M entrée$/M sortieContexteParticularité
anthropic/claude-opus-5~5~251 Mmême tarif sur toutes les routes ; cache à ~0,50 $/M
x-ai/grok-4.6~2~6500 ktarif doublé au-delà de 200 k tokens de prompt
moonshotai/kimi-k3~3~151 Mopen weights au niveau frontier — le pont vers le sous-thème B

Config — les sièges du jugement du roster frontier

Un extrait de la pièce du jour : les deux sièges où ce roster dépense son budget. Le fichier complet est dans les travaux pratiques, même schéma que le roster du chapitre 15, seuls les moteurs et la réflexion changent.

# frontier.config.yaml (extrait) — les sieges ou une decision se prend.
# Prix releves le 2026-09-01 : des reperes dates, pas des verites.
  - name: planner
    purpose: Transformer une demande en plan que le builder implemente sans questions.
    model: anthropic/claude-opus-5   # ~5 $/M in, ~25 $/M out — le plan porte tout le run
    thinking: high
    writes:
      - specs/

  - name: reviewer
    purpose: Confirmer que ce qui est construit est ce qui etait demande ; ne rien changer.
    model: anthropic/claude-opus-5   # le meme jugement que celui qui a signe le plan
    thinking: high
    writes: []

Piège courant : « mettre Opus partout, c’est l’usine la plus sûre » est inexact. Le jugement ne vaut que là où une décision se prend. Sur les voies mécaniques (reconnaissance, rédaction d’après diff), le surcoût d’un frontier n’achète ni vitesse ni qualité mesurable : il multiplie juste la facture des phases qui n’en avaient pas besoin. Le roster frontier concentre sa dépense sur le plan et la revue, c’est sa définition.


Les open weights : GLM, Kimi, DeepSeek, Grok

L’idée en une phrase

Un modèle open weights a ses poids publiés : n’importe quel hébergeur peut le servir, et l’identifiant du registre devient un marché de routes concurrentes. La pièce du jour, open-weights.config.yaml, staffe l’usine entière sur ces moteurs, toujours côté code déterministe, sans toucher un script.

Points clés

  • Poids publiés = concurrence sur la route. Au relevé du 1er septembre 2026, z-ai/glm-5.3 est servi par une vingtaine de routes entre ~1,20 et ~1,75 $/M en entrée, et moonshotai/kimi-k3 (1 M de contexte) par une quinzaine, autour de ~3/15 $/M. La concurrence tire les prix vers le bas, et le failover du chapitre 15 y gagne aussi.
  • Même identifiant, précision variable. Les routes annoncent leur quantification (fp4, fp8, bf16…) : le même modèle, servi avec des poids plus ou moins compressés. Moins cher et plus rapide en quantifié, mais pas strictement identique. Sur un siège de jugement, la nuance compte.
  • DeepSeek joue sur deux étages. Le léger de votre roster (deepseek/deepseek-v4-flash-0731, ~0,03 à 0,44 $/M selon la route) a un grand frère : deepseek/deepseek-v4-pro-0813, ~0,70 à 1,30 $/M en entrée, du jugement à prix de workhorse, avec des heures creuses chez l’éditeur où le tarif est environ divisé par deux selon la fenêtre horaire UTC.
  • Grok est le cas frontière de la famille. Son éditeur publie les poids de générations précédentes, mais la génération courante, celle du registre, reste fermée derrière l’API. Ce que vous branchez aujourd’hui est un frontier fermé à prix d’open weight.
  • La souveraineté vient avec les poids. Un open weight peut être servi par un hébergeur de votre juridiction, sous vos conditions de rétention, un argument qui ne dépend d’aucun benchmark.

Exemple concret

Suivez une phase de build de Plume sur le roster open weights : le builder tourne sur Kimi K3 via la route que la passerelle choisit ce jour-là, fp8 chez l’un, mxfp4 chez l’autre, de ~2,55 à ~3,45 $/M en entrée selon le stand. La phase coûte ~15 à 25 centimes, dans la même fourchette qu’hier sur GLM. Maintenant regardez le planner : GLM 5.3 y remplace Opus pour un cinquième du prix d’entrée environ, et c’est précisément la question que ce roster pose à votre usine : que perd le plan, concrètement, sur vos demandes ? Aujourd’hui vous ne pouvez que le deviner. Demain, adw_bench le mesurera en euros et en gates passées.

Le marché des open weights, relevé du 1er septembre 2026

MoteurRoutes$/M entréeSiège naturel
z-ai/glm-5.3~20~1,20 à 1,75plan, revue
moonshotai/kimi-k3~15~2,55 à 3,45build (1 M de contexte)
deepseek/deepseek-v4-pro-0813~15~0,70 à 1,30jugement économe, heures creuses
deepseek/deepseek-v4-flash-0731~20~0,03 à 0,44reconnaissance, rédaction

Commande — jauger les deux nouveaux rosters

Une seule version suffit ici : la jauge est du code déterministe pur, aucun harnais n’intervient, ni pi ni Claude Code. Deux commandes d’une ligne, valables telles quelles sous bash comme sous PowerShell :

# zero token : chaque moteur du roster frontier existe-t-il, a quel prix du jour ?
uv run adws/model_stack.py --config adws/adw_config/frontier.config.yaml

# meme verdict pour le roster open weights
uv run adws/model_stack.py --config adws/adw_config/open-weights.config.yaml

Piège courant : « même identifiant, même modèle, même résultat » est inexact. L’identifiant nomme les poids, pas le service : d’une route à l’autre changent la quantification, la fenêtre de contexte réellement servie et le prix. Pour un scout, la différence est invisible. Pour un siège de jugement, si un comportement vous surprend, regardez quelle route a servi la requête avant d’accuser le modèle.


Fil rouge — la pièce posée aujourd’hui

Deux fichiers dans la zone « moteurs » du plan : frontier.config.yaml et open-weights.config.yaml, posés à côté du roster de production du chapitre 15. Les voisins travaillent déjà : la jauge du chapitre 14 les valide à zéro token, la passerelle d’hier les facture sur la même clé, et brancher cinq moteurs de plus n’a ouvert aucun compte. La couture ne bouge pas : un roster est une déclaration que le code charge et applique, les agents changent de moteur sans le savoir. À l’usage : poser les deux fichiers coûte zéro token, les faire tourner, c’est l’arbitrage qu’ils matérialisent, quelques dollars le SDLC frontier, quelques dizaines de centimes en open weights. Honnêteté chronologique : vos ADW lisent encore factory.config.yaml en dur. Demain, chapitre 17, l’option --config traversera tous les scripts et adw_bench départagera les rosters sur vos propres flux.


Travaux pratiques — la pièce du jour

Une pièce complète à poser dans le repo compagnon plume-factory, qui devient, chapitre après chapitre, votre usine logicielle agentique. Aujourd’hui, deux fichiers : deux équipes complètes de plus dans adws/adw_config/. Aucun script ne change, et la gate ne coûte pas un centime : ces rosters ne dépenseront rien tant que le chapitre 17 ne les aura pas branchés aux ADW.

Pièce — adws/adw_config/frontier.config.yaml

Le roster tout jugement : Opus 5 au plan et à la revue, Kimi K3 au build, Grok 4.6 en reconnaissance. Même schéma que factory.config.yaml (chapitre 15) : mêmes cinq agents, mêmes permissions, mêmes fichiers protégés, seuls les moteurs et la réflexion changent.

# frontier.config.yaml — la meme usine, staffee tout jugement.
# Rien d'autre ne change : memes ADW, memes prompts, memes gates, meme cle.
# Ce roster echange des tokens contre du jugement — reservez-le aux demandes
# ou un plan rate coute plus cher que la difference de facture.
# Prix releves le 2026-09-01 sur le registre — des fourchettes datees.
defaults:
  harness: pi                    # pi | claude — les deux adaptateurs du port (ch. 7)
  model: x-ai/grok-4.6           # frontier d'entree : ~2 $/M in, ~6 $/M out
                                 # (tarif double au-dela de 200 k tokens de prompt)
  thinking: high
  tools: [read, bash, grep, find, ls]
  protected_files:
    - adws/adw_modules/
    - adws/adw_config/
    - adws/adw_*.py
    - PLAN.md
  data_dir: adws/adw_data        # le runtime : TOUJOURS ouvert, jamais commite

agents:
  - name: scout
    purpose: Reperer ou vivent les choses dans le repo ; ne rien changer.
    # herite du defaut grok-4.6 : la reconnaissance frontier la moins chere
    thinking: low
    writes: []
    tools: [read, bash, grep, find, ls, write]

  - name: planner
    purpose: Transformer une demande en plan que le builder implemente sans questions.
    model: anthropic/claude-opus-5     # ~5 $/M in, ~25 $/M out — le plan porte tout le run
    thinking: high
    writes:
      - specs/
    tools: [read, bash, grep, find, ls, write]

  - name: builder
    purpose: Implementer le plan, exactement ; declarer chaque fichier modifie.
    model: moonshotai/kimi-k3          # ~3 $/M in, ~15 $/M out — 1 M de contexte,
    thinking: high                     # open weights au niveau frontier
    tools: [read, bash, grep, find, ls, edit, write]

  - name: reviewer
    purpose: Confirmer que ce qui est construit est ce qui etait demande ; ne rien changer.
    model: anthropic/claude-opus-5     # le meme jugement que celui qui a signe le plan
    thinking: high
    writes: []

  - name: documenter
    purpose: Rediger apres coup ce qui a change et pourquoi ; n'ecrire que sous app_docs/.
    model: moonshotai/kimi-k3          # un long diff lu de bout en bout, redige une fois
    thinking: medium
    writes:
      - app_docs/
    tools: [read, bash, grep, find, ls, write]

Pièce — adws/adw_config/open-weights.config.yaml

Le roster tout poids publiés : GLM 5.3 aux sièges de jugement, Kimi K3 au build, DeepSeek sur les voies mécaniques. La question qu’il matérialise : que valent les meilleurs open weights sur vos propres flux, à une fraction du prix frontier ?

# open-weights.config.yaml — l'usine entiere sur poids publies.
# Chaque moteur ici peut etre servi par n'importe quel hebergeur : prix
# tires par la concurrence, souverainete possible, quantifications variables.
# Prix releves le 2026-09-01 sur le registre — des fourchettes datees.
defaults:
  harness: pi
  model: deepseek/deepseek-v4-flash-0731   # leger : ~0,03-0,44 $/M in selon la route
  thinking: medium
  tools: [read, bash, grep, find, ls]
  protected_files:
    - adws/adw_modules/
    - adws/adw_config/
    - adws/adw_*.py
    - PLAN.md
  data_dir: adws/adw_data

agents:
  - name: scout
    purpose: Reperer ou vivent les choses dans le repo ; ne rien changer.
    # herite du leger par defaut : la reconnaissance est une voie mecanique
    thinking: low
    writes: []
    tools: [read, bash, grep, find, ls, write]

  - name: planner
    purpose: Transformer une demande en plan que le builder implemente sans questions.
    model: z-ai/glm-5.3                # ~1,20-1,75 $/M in — le jugement open weights
    thinking: high
    writes:
      - specs/
    tools: [read, bash, grep, find, ls, write]

  - name: builder
    purpose: Implementer le plan, exactement ; declarer chaque fichier modifie.
    model: moonshotai/kimi-k3          # 1 M de contexte, solide a l'outil — deja
    thinking: high                     # builder du roster frontier : bon etalon
    tools: [read, bash, grep, find, ls, edit, write]

  - name: reviewer
    purpose: Confirmer que ce qui est construit est ce qui etait demande ; ne rien changer.
    model: z-ai/glm-5.3                # variante econome : deepseek/deepseek-v4-pro-0813,
    thinking: high                     # jugement a ~0,70-1,30 $/M in, heures creuses en prime
    writes: []

  - name: documenter
    purpose: Rediger apres coup ce qui a change et pourquoi ; n'ecrire que sous app_docs/.
    # modele et thinking herites des defauts : rediger d'apres un diff
    # est un travail de rapport, pas de decision.
    writes:
      - app_docs/
    tools: [read, bash, grep, find, ls, write]

La gate du TP

Deux commandes à la racine de plume-factory, une par ligne. Zéro token, ~2 secondes chacune, réseau requis :

uv run adws/model_stack.py --config adws/adw_config/frontier.config.yaml
uv run adws/model_stack.py --config adws/adw_config/open-weights.config.yaml

Attendu : jauge : OK deux fois. Chaque moteur existe au registre, prix du jour et étage à l’appui, et la ligne d’écart d’étages chiffre l’amplitude de chaque roster. Ne soyez pas surpris de voir Grok 4.6 classé workhorse : la jauge lit les prix, pas les capacités. Les seuils du chapitre 14 sont des repères de lecture, et ce roster vient d’en donner la preuve. Quand les deux verdicts sont verts, commitez les deux fichiers.


Quiz — teste tes connaissances
Model stack 7 questions Objectif : 5/7 minimum
0/7
bonnes reponses
Objectif non atteint (minimum 5/7 requis).
Remonte relire la fiche memo en pretant attention aux points manques, puis cliquer sur « Recommencer » pour retenter.