Créer une chat completion

Où l'appel tourne, ce qu'il coûte

Ce qui arrive à l'opérateur

Evanesca transmet le corps de la requête à l'opérateur qui sert le modèle : les paramètres d'OpenAI se comportent comme OpenAI les documente, et un paramètre qu'un opérateur ne prend pas en charge est ignoré par lui. Deux exceptions gardent le routage et la facturation chez Evanesca : les champs qui demanderaient à un routeur de choisir un autre modèle ou un autre hébergeur — models, provider, plugins — sont retirés, et un max_tokens au-dessus du plafond de l'opérateur pour ce modèle est ramené à ce plafond au lieu d'échouer.

La réponse est un objet chat.completion standard. Son champ model porte le nom que l'opérateur donne au modèle qui a répondu ; son bloc usage est ce que votre crédit paie, au token près.

Streaming

Avec "stream": true, la réponse arrive en server-sent events : des lignes data: qui portent des fragments au format OpenAI, jusqu'à data: [DONE]. C'est le format d'OpenAI, donc les fonctions de streaming des SDK marchent telles quelles.

Evanesca demande toujours l'usage à l'opérateur dans le flux (stream_options.include_usage) : le dernier fragment avant [DONE] porte l'objet usage et un tableau choices vide. C'est lui qui permet de facturer un appel en streaming au token près — attendez-vous à le voir si vous lisez le flux vous-même.

Appel d'outils

Envoyez tools et tool_choice au format OpenAI : Evanesca les transmet tels quels à l'opérateur, et les appels d'outils reviennent dans message.tool_calls (ou en fragments si vous streamez). Qu'un modèle en émette dépend du modèle et de son opérateur : le catalogue l'indique modèle par modèle, d'après un vrai appel plutôt qu'une fiche de modèle.

Tous les modèles du tableau renvoient des appels d'outils.

Dans GET /models, tool_calling vaut true ou false là où il a été mesuré, et manque là où il ne l'a pas été : filtrez dessus avant de déployer un agent.

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Météo actuelle d'une ville",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    },
}]

answer = client.chat.completions.create(
    model="gemma-4-26b",
    messages=[{"role": "user", "content": "Quel temps fait-il à Lyon ?"}],
    tools=tools,
)
print(answer.choices[0].message.tool_calls)

Modèles de raisonnement

Ces modèles réfléchissent avant de répondre : deepseek-v4.1-flash, glm-5.3, qwen3.8-27b, deepseek-v4-flash, glm-5.2, qwen3.6-35b, qwen3.5-397b, gpt-oss-120b. Cette réflexion est faite de tokens de complétion : elle est facturée en sortie, au prix de sortie du modèle, avant le moindre texte visible. Sur tout modèle, les tokens de raisonnement que l'opérateur rapporte comptent comme de la sortie.

Laissez-leur de la marge. Avec un max_tokens bas, tout le budget peut partir dans la réflexion, et la réponse revient sans contenu, avec finish_reason "length" : elle paraît vide, mais rien n'a échoué. Omettez max_tokens, ou laissez au moins 1 000 tokens environ.

La réflexion prend aussi du temps : sur un long prompt, un modèle comme deepseek-v4.1-flash peut travailler plusieurs minutes avant que la réponse soit complète. Relevez le délai d'attente de votre client HTTP (le nœud OpenAI Chat Model de n8n, par exemple, coupe à 60 secondes par défaut) ou streamez la réponse.

Erreurs

Les autres erreurs d'opérateur vous parviennent avec son statut et son corps, et Retry-After quand il en envoie un (erreurs).