Paramètres pris en charge

Le protocole est iso-OpenAI et la surface de paramètres en est un sous-ensemble documenté. Ce qui est honoré, ce qui est accepté sans effet, et ce qui donne un 400 qui le nomme.

chat.completions.create prend le type de requête d'OpenAI : TypeScript vous laissera donc renseigner n'importe quel champ déclaré par OpenAI. Ce que le proxy Fleeex accepte à l'intérieur de cette requête est plus étroit : un large sous-ensemble, mais un sous-ensemble. Cette page en donne la liste.

L'échec est bruyant plutôt que discret. Une seule règle décide du sort d'un paramètre :

Un paramètre qui changerait la réponse, la facturation ou une garantie que Fleeex laisserait entendre donne un 400 qui le nomme, car l'ignorer en silence vous remettrait une mauvaise réponse que vous ne pourriez pas détecter. Un paramètre qui ne change rien d'observable est accepté et ignoré, car un 400 casserait là une intégration sans rien apporter.

Honorés

Transmis au modèle, et facturés en conséquence.

Acceptés sans effet

Validés, puis ignorés, car ils ne changent rien d'observable. Le SDK OpenAI, LangChain, LiteLLM et le SDK Vercel AI en envoient plusieurs par défaut : les refuser coûterait donc une intégration sans rien apporter.

Un champ décoratif à une seule valeur voit cette valeur épinglée plutôt que d'être laissé passer : n: 1 est décoratif, n: 2 demande deux complétions qui ne sont pas produites, et n'en renvoyer qu'une serait à la fois une mauvaise réponse et une question de facturation.

Un null explicite se lit comme « non renseigné » sur tout champ optionnel. C'est ainsi que plusieurs clients OpenAI sérialisent un champ qu'ils n'ont pas posé : il est donc normalisé plutôt que transmis.

Refusés : un 400 qui nomme le paramètre

Le message nomme chaque paramètre refusé et liste les paramètres acceptés, lus sur le schéma de requête lui-même : rien de tout cela n'a donc à être découvert par tâtonnement.

{
  "error": {
    "code": "BAD_REQUEST",
    "message": "Unsupported parameter: 'seed'. Accepted: model, messages, max_completion_tokens, …",
    "correlationId": "…"
  }
}

max_completion_tokens dimensionne la réservation

max_completion_tokens est le nom actuel chez OpenAI, max_tokens le nom déprécié. Les deux sont acceptés, et le nouveau nom l'emporte si vous envoyez les deux. Aucun des deux n'est un simple plafond posé au modèle : ce nombre dimensionne aussi la réservation que Fleeex pose sur le portefeuille avant d'appeler le fournisseur. Une valeur inutilement grande peut donc se transformer en 402 sur un portefeuille qui aurait couvert la réponse réelle. La valeur par défaut est 1024.

Limites

Des bornes de taille, pour qu'aucun champ ne puisse être arbitrairement gros. Toutes donnent un 400.

La version toujours à jour

Cette page suit la description OpenAPI de la route elle-même, POST /v1/chat/completions, générée à partir du schéma de requête et donc faisant autorité. Si les deux venaient à diverger, c'est la route qui l'emporte.