Supprimez temperature et top_p — ainsi que logprobs et top_logprobs — des requêtes adressées aux modèles de raisonnement. Les recommandations d’OpenAI autorisent l’échantillonnage sur GPT-5.1, 5.2 et 5.4, ainsi que sur GPT-6 Sol et Luna, uniquement avec un effort de raisonnement none ; gpt-5, gpt-5-mini et gpt-5-nano les rejettent quel que soit le réglage, et GPT-6 Astra ne propose aucun réglage none utilisable. La sortie se pilote plutôt avec l’effort de raisonnement, la verbosité et le prompt.
L’erreur
{
"error": {
"message": "Unsupported value: 'temperature' does not support 0.2 with this model. Only the default (1) value is supported.",
"type": "invalid_request_error",
"param": "temperature",
"code": "unsupported_value"
}
}
# 0.2 is whatever your code sent; reports show 0 and 0.7 too.
# Some models reject the field at any value instead:
# "Unsupported parameter: 'temperature' is not supported with this model."
# "Unsupported parameter: 'top_p' is not supported with this model."
# (code "unsupported_parameter")Causes et solutions en bref
| Cause | Solution |
|---|---|
| Un modèle de raisonnement exécuté avec un effort de raisonnement supérieur à none | Supprimez temperature, top_p, logprobs et top_logprobs de la requête. |
| Un modèle sans réglage none — gpt-5, gpt-5-mini, gpt-5-nano, GPT-6 Astra | N’envoyez jamais ses paramètres d’échantillonnage ; pilotez-le avec l’effort et la verbosité. |
| Une valeur par défaut de votre pile que vous n’avez jamais définie (0.7 dans LangChain, 0 dans Cline) | Remplacez ou supprimez la valeur par défaut pour chaque modèle avant l’envoi de la requête. |
| Envoyer la valeur par défaut 1 par précaution | Omettez plutôt le champ : certains modèles rejettent le paramètre quelle que soit sa valeur. |
Supprimer les paramètres d’échantillonnage
Il s’agit d’une suppression, et non d’une nouvelle valeur. Omettez entièrement temperature et top_p des appels aux modèles de raisonnement, ainsi que logprobs et top_logprobs, couverts par la même règle. Si vous voulez modifier la quantité de travail du modèle, l’effort de raisonnement est le réglage restant.
from openai import OpenAI
client = OpenAI(base_url="https://api.kunavo.com/v1", api_key="sk-kn-...")
msgs = [{"role": "user", "content": "Summarize this diff as three changelog bullets."}]
# Before — sampling parameters on a reasoning model
resp = client.chat.completions.create(
model="gpt-6-astra", temperature=0.2, top_p=0.9, messages=msgs)
# After — removed; reasoning effort is the control that remains
resp = client.chat.completions.create(
model="gpt-6-astra", reasoning_effort="low", messages=msgs)Vérifier quels modèles acceptent l’échantillonnage
OpenAI énonce la règle pour chaque famille de modèles, et celle-ci dépend de l’effort de raisonnement. Voici ses recommandations telles qu’elles étaient disponibles le 23 septembre 2026. Les pages GPT-5.5 et GPT-5.6 ne reformulent pas la règle ; considérez donc ce silence comme une raison de tester, et non comme une permission. Les lignes consacrées aux modèles de la série o proviennent de rapports d’erreur plutôt que de la documentation.
gpt-5, gpt-5-mini, gpt-5-nano error, whatever the reasoning setting
GPT-5.1, GPT-5.2, GPT-5.4 accepted only with reasoning effort "none"
GPT-6 Sol, GPT-6 Luna remove them unless reasoning effort is "none"
GPT-6 Astra remove them: Astra has no "none" effort
GPT-5.5, GPT-5.6 not stated on their guidance pages
o1-preview, o3-mini rejected (reported errors, not docs)Piloter le modèle avec les contrôles qui l’ont remplacé
Les recommandations d’OpenAI citent trois substituts lorsque le raisonnement est activé : la profondeur du raisonnement (reasoning.effort, dont les valeurs dépendent du modèle et vont de none et minimal jusqu’à xhigh et max), la verbosité de sortie (text.verbosity : low, medium ou high, medium par défaut) et la longueur de sortie (max_output_tokens, qui compte aussi bien les tokens de raisonnement que ceux visibles). Chat Completions nomme les deux premiers reasoning_effort et verbosity. Les recommandations ne proposent aucun équivalent au niveau de l’échantillonnage pour temperature 0 ; si vous l’utilisiez pour rendre la sortie reproductible, figez plutôt sa structure, avec Structured Outputs pour le schéma et le prompt pour le reste.
# client as in fix.py above
resp = client.responses.create(
model="gpt-5-6-sol",
input="Summarize this diff as three changelog bullets.",
reasoning={"effort": "low"}, # how much it thinks
text={"verbosity": "low"}, # how much it says
max_output_tokens=2000, # hard cap, reasoning tokens included
)
print(resp.output_text)Placer la règle dans un helper unique
Un branchement à chaque point d’appel est la façon de transformer l’arrivée de la prochaine famille de modèles en une nouvelle série de modifications. Filtrez une seule fois les paramètres d’échantillonnage, en fonction du modèle et de l’effort que vous allez envoyer ; sur un modèle qui prend en charge l’effort none, ils sont transmis lorsque vous demandez none.
SAMPLING = ("temperature", "top_p", "logprobs", "top_logprobs")
REASONING = ("gpt-5", "gpt-6", "o1", "o3", "o4") # extend as you adopt models
def sampling_params(model: str, effort: str | None, **params) -> dict:
"""Keep sampling parameters only where they are accepted: effort "none"."""
if model.startswith(REASONING) and effort != "none":
return {k: v for k, v in params.items() if k not in SAMPLING}
return params
effort = "low" # client and msgs as in fix.py above
resp = client.chat.completions.create(
model="gpt-5-6-terra",
messages=msgs,
reasoning_effort=effort,
**sampling_params("gpt-5-6-terra", effort, temperature=0.2, top_p=0.9),
)Si vous appelez via Kunavo
Kunavo ne supprime ni ne réécrit temperature ou top_p pour les modèles GPT, sur aucun des deux endpoints. Sur /v1/chat/completions, il reconstruit la requête pour l’amont Responses : temperature et top_p sont copiés sans modification, reasoning_effort devient reasoning.effort et chacune des variantes de plafond de tokens devient max_output_tokens, tandis que les champs hors de cette correspondance — notamment verbosity, logprobs, top_logprobs, seed et stop — ne sont pas transmis du tout ; définissez donc verbosity via /v1/responses. Sur cet endpoint, vos champs d’échantillonnage et de texte sont transmis exactement comme envoyés, y compris text.verbosity. Si le modèle rejette une valeur, le 400 contient son message mot pour mot dans l’enveloppe Kunavo (type upstream_error, code upstream_400) ; faites donc la correspondance sur le statut ou le message, et non sur le code "unsupported_value" ; l’appel échoué n’est pas facturé. Un appel qui réussit avec temperature défini ne prouve pas que la valeur a été appliquée. Kunavo ne supprime temperature, top_p et top_k lui-même que pour les six modèles Claude desquels Anthropic les a retirés — claude-fable-5-1, claude-fable-5, claude-opus-5, claude-opus-4-8, claude-opus-4-7 et claude-sonnet-5 — et le fait sur chaque endpoint. L’autre moitié de la même migration, max_tokens contre max_completion_tokens, est expliquée dans le guide max_tokens.
Questions fréquentes
Puis-je définir temperature sur GPT-5 ?
Pas sur gpt-5, gpt-5-mini ou gpt-5-nano : OpenAI indique que les requêtes qui l’incluent génèrent une erreur. GPT-5.1, 5.2 et 5.4 acceptent temperature, top_p et logprobs uniquement lorsque l’effort de raisonnement est défini sur none, et les recommandations d’OpenAI pour GPT-6 indiquent de les supprimer dès que l’effort de raisonnement n’est pas none.
Qu’est-ce qui remplace temperature sur les modèles de raisonnement ?
L’effort de raisonnement pour déterminer la quantité de réflexion du modèle, text.verbosity (verbosity dans Chat Completions) pour déterminer la quantité de texte produite, et max_output_tokens comme plafond strict. Avec Kunavo, définissez verbosity sur /v1/responses : l’endpoint chat ne le transmet pas aux modèles GPT. Pour une structure reproductible, utilisez Structured Outputs et des règles de format explicites dans le prompt.
Devrais-je simplement envoyer temperature=1 ?
Omettez-le. Le message Valeur non prise en charge indique que la valeur par défaut 1 est acceptée sur le modèle qui l’a produit, mais que d’autres modèles rejettent le paramètre quelle que soit sa valeur ("Unsupported parameter: 'temperature' is not supported with this model"), et les recommandations d’OpenAI préconisent de supprimer les champs.
Pourquoi cette erreur apparaît-elle alors que mon code ne définit jamais temperature ?
Un élément de votre pile l’a défini. Les appels o1-preview d’un utilisateur de jupyter-ai contenaient 0.7, la valeur par défaut de la classe ChatOpenAI de LangChain utilisée par jupyter-ai, et un contributeur de Cline a attribué la valeur 0 rencontrée par un utilisateur de GPT-5 à une valeur par défaut codée en dur. Vérifiez ce que votre SDK ou framework place réellement sur le réseau, puis remplacez ou supprimez cette valeur selon le modèle.
Kunavo supprime-t-il temperature à ma place ?
Pas pour les modèles GPT : Kunavo transmet temperature et top_p exactement comme vous les envoyez, aussi bien sur /v1/chat/completions que sur /v1/responses. Il supprime temperature, top_p et top_k pour les six modèles Claude desquels Anthropic les a retirés.
Guides associés
- « Unsupported parameter: 'max_tokens' is not supported with this model » — utilisez max_completion_tokens
- « `temperature` et `top_p` ne peuvent pas être spécifiés simultanément pour ce modèle » — envoyez-en un seul, et aucun avec les modèles Claude plus récents
- Guide des API compatibles OpenAI — de l'endpoint local d'Ollama aux modèles avancés hébergés
- Limites de débit de l’API OpenAI — quelle limite vous atteignez, comment la lire et quelle nouvelle tentative la corrige
La sémantique détaillée des erreurs est disponible dans référence des erreurs ; obtenir une clé prend une minute via inscription et la guide d’authentification.