Après le passage de l'API Decisions OpenAI en disponibilité générale le 22 octobre 2026, le routage de tickets Agent doit-il utiliser input_json ou JSON Schema ?

Dans un agent vous routez les tickets vers des services : certaines équipes enfouissent tout le JSON dans le prompt, d'autres attachent un json_schema sur Responses pour obtenir {"department":"billing"}. Decisions est une troisième voie : preuves via input_json, routage via une question choice, réponse qui lit directement le champ choice. Traiter les trois API comme un seul Schema et la couche de routage parse les mauvais champs.

Ce que la GA du 22 octobre a changé

Au 24/10/2026, d'après le journal des changements et le guide Decisions (marqué GA, avec les deltas post-bêta listés) :

• Modèle : toujours uniquement gpt-6-luna.
• Échelle : jusqu'à questions par appel : de 200 à 400.
• Preuves : nouvelle partie de contenu input_json ; l'input partagé peut porter conversation, appels de fonction et sorties (alignés via call_id).
• Exploitation : l'input partagé peut utiliser le prompt caching ; les instructions par question peuvent inclure des images ; intégration native avec GPT-Live.

La bêta publique est arrivée le 06/10/2026 ; la GA est datée du 22/10/2026. La doc dit encore environ 10× plus rapide que Responses — adapté à la classification, au routage et à la priorité, pas aux longs rapports ni aux formes d'objet arbitraires.

Trois blocs de requête : model, input, questions

Le guide découpe une décision en model, input (preuves partagées par toutes les questions) et questions (type, consignes, choix ou niveaux par question). Chaque question doit avoir un name unique ; answers s'aligne sur ce nom.

Trois types de questions fixes :

• predicate : une condition tient-elle ; champ principal probability (0 à 1).
• choice : choisir un choices[].value ; champ principal choice.
• score : niveaux ordonnés ; champ principal score (moyenne pondérée par probabilité des indices de niveau, peut se situer entre deux paliers).

input peut être une chaîne simple ou un tableau de messages. Les messages user peuvent inclure texte, images et JSON ; appels d'outil et sorties peuvent servir de preuves, mais Decisions ne renvoie que des réponses — il n'exécute pas les outils pour vous.

input_json sur le contenu user

L'exemple ticket du guide met commande et ticket dans data, à côté de input_text sur le même message user :

{
  "model": "gpt-6-luna",
  "input": [
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "Evaluate the ticket using the order evidence."
        },
        {
          "type": "input_json",
          "data": {
            "ticket": { "body": "Please refund the duplicate charge." },
            "order": { "charges": [49, 49] }
          }
        }
      ]
    }
  ],
  "questions": [
    {
      "type": "predicate",
      "name": "duplicate_charge",
      "instructions": "Does the ticket describe a duplicate charge supported by the order?"
    }
  ]
}

La doc insiste : des clés comme role ou image_url dans data sont du JSON ordinaire — elles ne deviennent pas un second message et ne chargent pas une image distante. Seule une partie input_image externe charge une image.

input_json est uniquement pris en charge sur le rôle user. Ne mettez pas la même structure sur des messages developer ou assistant.

answers n'est pas du JSON libre

Exemple de réponse predicate :

{
  "answers": [
    {
      "type": "predicate",
      "name": "duplicate_charge",
      "probability": 0.91
    }
  ]
}

Pour router une réclamation, utilisez choice avec value et description sur chaque entrée de choices ; lisez answers[].choice — ne parsez pas une couche JSON imbriquée de plus.

Les exemples SDK testent d'abord answer.type === "refusal". Traitez les refus à part des probabilités ou choix normaux ; ne les mappez pas à probability: 0.

Avec plusieurs questions, indexez par name ; ne supposez pas que l'ordre de answers colle toujours à questions (même si les exemples correspondent souvent).

Choisir face à la sortie structurée JSON Schema

Formulation du guide : besoin d'un objet selon votre JSON Schema (extraction de champs, prose) → Structured Outputs sur Responses ; besoin d'appels d'outil → function calling ; besoin seulement de « probabilité / options fixes / score ordonné » → Decisions.

• Router vers billing / technique : choice plus un peu d'input_json, en général moins de latence qu'un json_schema.
• Extraire nom, adresse, lignes de commande : garder text.format json_schema, puis valider en local avec la validation de Schema.
• Le modèle doit appeler votre API : function calling ; la sortie d'outil Decisions n'est qu'une preuve — elle ne déclenche pas HTTP toute seule.

input_json règle le côté entrée pour éviter le stringify ; il ne remplace pas un Schema de sortie. Ne forcez pas answers dans des validateurs écrits pour Structured Outputs — noms de champs et sémantique ne correspondent pas.

Vérifier dans la boîte à outils

Quatre extraits locaux ci-dessous : les deux premiers sont le JSON de preuve que vous POSTeriez ; les deux derniers montrent comment lire les réponses (il faut toujours appeler l'API en ligne pour le trafic réel).

{
  "evidence_ok": {
    "ticket": { "body": "Please refund the duplicate charge." },
    "order": { "charges": [49, 49] }
  },
  "evidence_stringified": "{\"ticket\":{\"body\":\"refund\"}}",
  "answer_predicate_ok": {
    "type": "predicate",
    "name": "duplicate_charge",
    "probability": 0.91
  },
  "answer_wrong_shape": {
    "department": "billing",
    "confidence": 0.91
  }
}

1. Collez les quatre dans le formatage JSON. La valeur de evidence_stringified est une chaîne, pas un objet — c'est pourquoi il ne faut plus stringify.
2. Avec JSON → Schema, partez de evidence_ok pour figer la forme des preuves ticket côté dépôt ; ce n'est pas le schéma de requête Decisions.
3. Si vous avez écrit un schéma Structured Outputs du type {"department":"string"}, answer_predicate_ok ne doit pas le passer ; answer_wrong_shape ne doit pas passer pour une réponse predicate non plus.
4. Les contrats d'entrée d'outil passent par les appels de fonction ; les objets libres par la sortie structurée.

Les données restent dans le navigateur. Séparez « objet de preuve » et answers typées avant de modifier le routage agent.

Questions fréquentes

input_json change-t-il la forme des champs dans answers ?

Non. Le type de question vient toujours de questions[].type.

Peut-on utiliser Decisions comme remplaçant de json_schema pour Structured Outputs ?

Non. Les objets libres passent par Responses ; Decisions n'a que trois types de réponse.

input_json peut-il figurer dans un message assistant ?

Non. Seul le contenu des messages user le prend en charge.

Combien de questions peut-on poser dans une requête ?

400 après la GA ; chaque question a un name unique.

Comment cette note se distingue-t-elle de l'article Claude output_config ?

Cet article couvre l'objet JSON final Claude ; celui-ci couvre le tableau answers OpenAI.

En bref

Au 24/10/2026, la GA de l'API Decisions est datée du 22/10/2026. Point d'entrée POST /v1/decisions, modèle gpt-6-luna. Mettez les preuves structurées dans input_json.data sur un message user ; lisez le routage dans answers — probability, choice ou score. La sortie JSON Schema personnalisée reste sur Responses. Ensuite : figez l'objet de preuve en local, parsez answers par name, et n'appliquez pas les schémas Structured Outputs aux réponses de décision.

Outils liés

Articles liés