Avec 128 Mo, mettre tous les input_schema des outils MCP inline dans messages ?

En volume, peut-être, mais MCP doit encore utiliser mcp_tool_listing ou tools en tête pour la liste. En milieu de conversation, si vous ne changez que des références, ne touchez pas au tableau tools racine, sinon tout le prompt cache tombe. 128 Mo ne découple pas les règles de cache.

Comment se répartit le travail avec l'article sur le schema d'outil en cours de conversation ?

Cet autre article décrit inline-tools-2026-09-15 et mcp_tool_listing avec input_schema. Celui-ci : après le relâchement du plafond octets du 28/10/2026, faut-il encore découper le schema pour le volume, et comment valider avec count_tokens.

Claude 128 Mo et JSON Schema d'outil inline

Q: 128 Mo équivaut-il au contexte 1M tokens ?

Non. Les notes de version parlent de la taille maximale du corps HTTP. Token Counting compte toujours avec le tokenizer. Le même texte JSON Schema peut ne peser que quelques Mo et se traduire en énormément de tokens.

Q: L'API Token Counting supporte-t-elle aussi 128 Mo ?

Oui. La même note du 28/10/2026 monte Messages et Token Counting de 32 Mo à 128 Mo, limité à l'API Claude first-party. Avant messages.create, POSTez le même JSON sur count_tokens pour lire input_tokens.

Q: Le sous-ensemble input_schema avec strict: true a-t-il changé ?

Non. Une requête plus grosse ne change que l'envoi, pas additionalProperties: false et les autres règles du sous-ensemble. Un schema énorme peut encore renvoyer 400 sur les types de champs.

Comment lire cette note

Au 30/10/2026, les notes de version Claude du 28/10/2026 indiquent : pour l'API Messages et l'API Token Counting first-party, la taille maximale du corps passe de 32 Mo à 128 Mo. Les développeurs d'agents pensent vite qu'on peut mettre toute une bibliothèque OpenAPI en input_schema inline dans les messages — le volume peut passer, mais découper sert surtout à ne pas toucher au tableau tools racine et à garder le prompt cache, pas à contourner 32 Mo. Le contrat inline reste JSON Schema ; voir schema d'outil en cours de conversation. Sortie structurée : output_config.

À l'ère 32 Mo, vous copiez la liste MCP dans chaque tool_addition, ou placez output_config.format.schema à la racine à côté de centaines d'outils — 413. Avec 128 Mo, le 413 peut disparaître, la facture en tokens et les cache miss ne s'améliorent pas seuls.

Ce qui change le 28 octobre

Une seule ligne dans les notes, limitée à l'API Claude first-party (points de terminaison directs type api.anthropic.com) :

API Messages : plafond du corps HTTP par requête 32 Mo → 128 Mo.
API Token Counting (POST /v1/messages/count_tokens) : idem 32 Mo → 128 Mo, pour estimer input_tokens avant l'appel réel avec un JSON isomorphe.

La doc ne change pas la forme des inline tools, strict: true ou output_config. Ce qui change, c'est la taille maximale de la chaîne JSON acceptée à la passerelle, pas le tableau des capacités du modèle.

128 Mo et contexte 1M ne sont pas la même chose

Haiku 5.5 / Opus 5.5 et d'autres annoncent un contexte d'un million de tokens. C'est le budget après tokenisation, visible dans count_tokens et usage en réponse.

128 Mo : plafond du corps HTTP en octets UTF-8. JSON Schema imbriqués répétés, longues listes enum et pièces base64 consomment des octets.
input_tokens : le même corps peut faire 20 Mo et frôler la limite de contexte, le tokenizer n'aime pas les noms de clés répétés.
100 000 messages : la doc Messages indique toujours au plus 100 000 objets message par requête ; nombre et octets coexistent.

En une phrase. 128 Mo règle « JSON trop gros pour envoyer » ; découper le schema inline sert encore au cache et à la lisibilité, pas à la magie des tokens.

Où va le JSON Schema inline

Avec inline-tools-2026-09-15, les blocs tool_addition / tool_change peuvent porter le input_schema complet (type: object, properties, required). En MCP, mcp_tool_listing fixe la liste renvoyée par le serveur dans la session, sans modifier tools en tête à chaque tour.

{
  "model": "claude-haiku-5-5",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "Register the billing tool for this turn." },
        {
          "type": "tool_addition",
          "tool": {
            "name": "create_invoice",
            "description": "Create an invoice row",
            "input_schema": {
              "type": "object",
              "properties": {
                "customer_id": { "type": "string" },
                "amount_cents": { "type": "integer" }
              },
              "required": ["customer_id", "amount_cents"],
              "additionalProperties": false
            }
          }
        }
      ]
    }
  ]
}

Après 128 Mo, vous empilez plutôt plusieurs blocs ainsi dans de longues sessions, sans être bloqués à 32 Mo. Chaque schema complet fait encore monter input_tokens linéairement.

Quand il faut encore découper

Prompt cache : modifier le tableau tools à la racine invalide encore le cache suivant. N'ajouter que des blocs inline sans toucher tools en tête — fil directeur de l'article #13 — 128 Mo ne change pas la règle.
Schemas dupliqués : copier le même input_schema 50 fois sur 50 tours gaspille octets et tokens. Plus stable : une fois au premier tour via tools ou mcp_tool_listing, puis seulement tool_reference ou appel par nom.
output_config à côté : gros output_config.format.schema avec beaucoup d'outils — 128 Mo ne fait que relever le plafond dur ; valider le schema en local pour éviter un 400 qui brûle des tokens.
Outils strict + sortie structurée : deux contrats JSON dans le corps ; un plafond plus haut n'autorise pas à mélanger des champs que Bedrock ne supporte pas.

Valider le volume avec count_tokens

La même note du 28/10/2026 aligne le plafond counting sur 128 Mo. Méthode : POSTer messages, tools, system, output_config tels quels sur le point counting (sans max_tokens pour la génération).

{
  "estimate_ok": {
    "endpoint": "POST /v1/messages/count_tokens",
    "note": "Body matches the upcoming messages.create payload",
    "input_tokens": 184002,
    "body_bytes_approx": 9437184
  },
  "estimate_bad": {
    "endpoint": "POST /v1/messages/count_tokens",
    "input_tokens": 1200000,
    "body_bytes_approx": 134217728,
    "failure": "May exceed context even if under 128 MB"
  }
}

body_bytes_approx est la longueur UTF-8 mesurée côté passerelle ; l'API renvoie les tokens. Regarder les deux : le premier vs 128 Mo, le second vs le contexte 1M.

Bedrock et Google Cloud : ne pas supposer 128 Mo

La note vise l'API Claude first-party. Amazon Bedrock, Anthropic sur Google Cloud et Foundry ont leurs limites Invoke et couches d'emballage — 128 Mo ne s'applique pas automatiquement. Un agent multi-cloud avec un « JSON tools géant » peut envoyer en direct et obtenir 413 ou timeout sur Bedrock. Voir sortie structurée sur Bedrock et connexion Google Cloud.

Questions fréquentes

128 Mo équivaut-il au contexte 1M tokens ?

Non. L'un est le volume HTTP, l'autre le comptage du tokenizer.

Avec 128 Mo, mettre tous les input_schema MCP inline dans messages ?

Le volume peut suffire, mais cache et sémantique de liste : listing + référence.

L'API Token Counting supporte-t-elle aussi 128 Mo ?

Oui, même jour que Messages, API directe uniquement.

Le sous-ensemble input_schema avec strict: true a-t-il changé ?

Non. Un gros corps doit encore passer la validation du schema.

Comment se répartit le travail avec l'article schema en cours de conversation ?

L'autre explique l'inline ; celui-ci, après 128 Mo, s'il faut encore découper pour le volume.

Conclusion

Au 30/10/2026, le changement du 28/10/2026 sur l'API Claude first-party porte les corps Messages et Token Counting de 32 Mo à 128 Mo. Le JSON Schema inline en milieu de conversation reste dans tool_addition / input_schema du listing MCP, règles de sous-ensemble inchangées. Ne pas abandonner le découpage à cause de 128 Mo : toucher tools en tête — cache perdu ; schemas répétés — tokens brûlés. Mesurer les tokens avec count_tokens, les octets en local. Sur Bedrock/GCP, vérifier les limites à part. Prochaine étape : pour la plus grosse requête agent, calculer longueur UTF-8 et input_tokens, puis décider si le schema va dans le listing.