Anthropic API 2026-10-21: temperature da 400, incluso con 1.0

Una petición a Claude con la versión de API 2026-10-21 devuelve HTTP 400 si incluye temperature, top_p o top_k, aunque use el valor predeterminado: temperature: 1.0 falla con “temperature: Extra inputs are not permitted”. Estos parámetros de muestreo controlan la aleatoriedad con la que el modelo elige cada token siguiente. La versión de la API se indica en la cabecera anthropic-version, que determina cómo la API Messages valida y responde a la petición; el valor anterior es 2023-06-01. Las versiones mayores de los SDK que Anthropic publicó el 21 de octubre (Python 2.0.0, TypeScript 1.0.0 y cinco más) envían la nueva versión por defecto. Esos SDK ya no incluyen los parámetros de muestreo, así que el 400 afecta al código que construye el cuerpo de la petición por su cuenta: clientes HTTP directos y campos adicionales en el cuerpo. Probamos ocho tipos de petición con ambas versiones en Claude Sonnet 4.6 y Claude Sonnet 5.5, comparamos dos versiones del SDK de Python y repetimos las pruebas a través de Synthorai.

TL;DR

• Con 2026-10-21, temperature, top_p y top_k devuelven 400 en Claude Sonnet 4.6 y Sonnet 5.5, incluido temperature: 1.0.
• 2026-10-21 también rechaza los bloques document en mensajes del asistente y citations en bloques de texto del usuario.
• El SDK de Python 2.x de Anthropic envía la clave en Authorization: Bearer; si una petición lleva ambas cabeceras, la API usa x-api-key.
• A través de Synthorai, las 32 peticiones devolvieron 200 con ambos SDK, incluidas las 12 que la API de Anthropic rechaza con 2026-10-21.

¿Qué peticiones devuelven 400 con la versión de API 2026-10-21?

Cinco cambios provocan los errores 400: los tres parámetros de muestreo, los bloques document colocados directamente en mensajes del asistente y el campo citations en bloques de texto de mensajes del usuario. Este campo contiene referencias desde un bloque de texto a un pasaje de un documento. La tabla recoge seis casos que fallan y dos que siguen funcionando. Enviamos cada caso una vez por modelo y versión directamente a la API de Anthropic. Un 200 indica que se aceptó la petición; un 400, que se rechazó con invalid_request_error.

Los mensajes de error con la nueva versión:

Claude Sonnet 5.5 ya rechazaba los valores de muestreo distintos de los predeterminados con 2023-06-01, aunque con otro mensaje (“`temperature` is deprecated for this model.”), y aceptaba temperature: 1.0. Con 2026-10-21 se ha eliminado el parámetro, por lo que también falla el valor predeterminado. Claude Sonnet 4.6 aceptaba todos los casos con la versión anterior. La guía de migración de Anthropic indica que las mismas reglas se aplican al recuento de tokens y a cada petición de un Message Batch (la API Batch, que ejecuta muchas peticiones de forma asíncrona con descuento). No fija una fecha de retirada para 2023-06-01.

¿Cómo se corrige cada error 400?

Elimina los tres parámetros de muestreo, mueve los documentos a mensajes del usuario y quita citations del texto que envíes como usuario. Las peticiones sin parámetros de muestreo usan los valores predeterminados, incluido temperature 1.0, igual que ya ocurría con las peticiones sin esos parámetros en 2023-06-01. Se siguen aceptando las citas en respuestas anteriores de Claude y "citations": {"enabled": true} en documentos.

Con el SDK de Python, esta petición funciona con ambas versiones:

import anthropic

client = anthropic.Anthropic()  # 2.x sends anthropic-version: 2026-10-21

message = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    # no temperature, top_p or top_k: the parameters no longer exist in 2.x
    messages=[{"role": "user", "content": "Summarize this memo in one sentence."}],
)
print(message.content[0].text)

Si una petición necesita un valor de temperature distinto del predeterminado en un modelo que aún lo admita, como Claude Sonnet 4.6, debe seguir usando la versión anterior. Si haces la llamada HTTP directamente, tienes que establecer la cabecera:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "max_tokens": 256, "temperature": 0.2,
       "messages": [{"role": "user", "content": "Pick a number from 1 to 100."}]}'

¿Qué ha cambiado en los SDK de Anthropic?

Las versiones mayores de los SDK que envían 2026-10-21 son Python 2.0.0, TypeScript 1.0.0, Go 2.0.0, Java 3.0.0, C# 13.0.0, PHP 1.0.0 y Ruby 2.0.0. Además de la versión de la API, cambian la forma de enviar la clave y cuántas credenciales puede tener un cliente. También pasan de la licencia MIT a Apache 2.0. Instalamos las versiones 1.17.0 (la última 1.x) y 2.3.0 del SDK de Python y configuramos ambas para usar un servidor de eco local, que registra las cabeceras y el cuerpo de cada petición recibida:

El argumento temperature se eliminó de los métodos de mensajes del SDK de Python en la versión 1.0.0. Por eso, los usuarios de Python solo reciben el 400 del servidor si usan extra_body (la opción del SDK que añade campos directamente al cuerpo de la petición) o clientes HTTP y bibliotecas que construyen el cuerpo por su cuenta. La cabecera Bearer funciona con ambas versiones de la API: una petición que solo llevaba Authorization: Bearer <key> también devolvió 200 con 2023-06-01. El cambio de autenticación y el de versión pueden desplegarse por separado.

¿Qué clave se usa cuando se envían ambas cabeceras?

La API de Anthropic usa x-api-key cuando una petición lleva ambas cabeceras. Enviamos cinco combinaciones de cabeceras con ambas versiones:

Un proxy o gateway delante de Claude puede atribuir la petición a una clave distinta de la que usa la API. Con el SDK 2.x, el código que añade una segunda clave mediante extra_headers={"X-Api-Key": other_key} ahora envía dos claves: la del cliente en Authorization y la otra en x-api-key. La API de Anthropic autentica la petición con other_key, pero un proxy que solo lea Authorization la atribuye a la clave del cliente. Así, las cuotas por clave, los registros y los límites de gasto pueden contabilizarse en la clave equivocada. La solución que propone la guía para el cliente es enviar la segunda clave como Authorization: Bearer <other_key>. En el proxy, hay que leer ambas cabeceras y aplicar la prioridad de la API (x-api-key primero) o rechazar las peticiones cuyas cabeceras lleven claves distintas.

¿Qué se pierde al eliminar temperature?

Eliminar temperature tiene menos impacto del que podría esperar un equipo que dependiera de temperature: 0. La guía de migración indica que Claude 4.7 y los modelos posteriores ya aceptan solo los valores predeterminados, así que para ellos no cambia nada. En un modelo que aún admite otros valores, como Claude Sonnet 4.6, las peticiones que reducían temperature para obtener respuestas más estables pierden ese efecto, y no hay otro ajuste que lo sustituya. Medimos cuánto aportaba: hicimos 20 peticiones por configuración a Sonnet 4.6 con 2023-06-01, añadiendo a cada una un identificador de petición aleatorio para que no hubiera dos iguales.

En estas respuestas cortas, Sonnet 4.6 dio resultados casi tan concentrados con la temperatura predeterminada como con 0, por lo que eliminar temperature: 0 apenas cambió nada. Tampoco temperature: 0 garantizaba el determinismo: devolvió dos números distintos en 20 intentos. El texto del prompt influyó más que el ajuste: sin el identificador de petición añadido, 42 fue la respuesta más frecuente (17 de 20 con temperature: 0); con él, fue 47. Si necesitas resultados repetibles, compara las respuestas en el código o guárdalas en caché; el parámetro de muestreo tampoco lo garantizaba antes.

¿Cómo gestiona Synthorai la versión de API 2026-10-21?

Synthorai acepta peticiones con cualquiera de las dos versiones de la API y de los SDK. Actualizar al SDK 2.x o enviar anthropic-version: 2026-10-21 no hace fallar una petición que antes funcionaba. Repetimos la matriz de 16 casos para ambos modelos a través de Synthorai con los dos valores de anthropic-version: las 32 peticiones devolvieron 200, incluidas las 12 que la API de Anthropic rechaza con 2026-10-21. Tanto el SDK de Python 1.17.0 (que envía x-api-key) como el 2.3.0 (que envía Authorization: Bearer) funcionaron con base_url="https://synthorai.io" y la misma clave. También funcionó temperature enviado mediante extra_body.

Synthorai lo gestiona así por cuatro motivos:

• Un modelo, varios proveedores. Un modelo Claude puede servirse desde la API de Anthropic, Amazon Bedrock o Google Cloud Vertex AI, y cada proveedor usa su propia cadena de versión. Synthorai envía a cada proveedor la versión que espera, así que la cabecera anthropic-version del cliente no determina cómo se valida la petición.
• Distintos clientes durante la migración. Los equipos actualizan los servicios de uno en uno, así que durante semanas una misma cuenta envía 2023-06-01 desde el SDK 1.x y 2026-10-21 desde el SDK 2.x. Aceptar ambas versiones permite migrar cada servicio a su ritmo, y la misma clave funciona con la cabecera de autenticación de cualquiera de los SDK.
• Cambios de modelo sin cambiar el código. El código que establece temperature: 0.2 para Claude Sonnet 4.6 sigue funcionando al cambiar el nombre del modelo a Claude Sonnet 5.5, que no admite ese parámetro, en lugar de fallar al hacer el cambio.
• Sin fallos por un valor predeterminado. temperature: 1.0 es el valor que el modelo usa de todos modos. Rechazarlo haría fallar la petición sin cambiar el resultado.

La contrapartida es que un 200 no implica que todos los parámetros hayan surtido efecto. Sonnet 5.5 solo admite los valores de muestreo predeterminados, así que enviarle temperature: 0.2 a través de Synthorai funciona, pero no reduce su aleatoriedad. Si el resultado depende de un valor de muestreo, compara las respuestas con y sin ese valor usando tus propios prompts; en la medición anterior, el efecto fue pequeño para respuestas cortas.

¿Qué debes revisar antes de actualizar?

Preguntas frecuentes

¿Por qué falla mi petición a Claude con “temperature: Extra inputs are not permitted”? La petición se envió con anthropic-version: 2026-10-21, que ya no incluye el parámetro temperature. Cualquier valor devuelve 400, incluido 1.0. Las nuevas versiones mayores de los SDK envían esa versión por defecto. Elimina el parámetro o fija 2023-06-01 para las peticiones que necesiten un valor distinto del predeterminado en un modelo que aún lo admita.

¿Se va a retirar anthropic-version 2023-06-01? Anthropic no ha anunciado una fecha de retirada para 2023-06-01: no aparece ni en la guía de migración ni en las notas de la API del 21 de octubre. Las peticiones que establecen la cabecera explícitamente mantienen el comportamiento anterior. Así, una petición concreta puede seguir usando temperature en Claude Sonnet 4.6.

¿La API de Anthropic sigue aceptando la cabecera x-api-key? La API de Anthropic acepta tanto x-api-key como Authorization: Bearer en ambas versiones; solo ha cambiado cuál envían los SDK. Si están presentes las dos cabeceras, la API usa x-api-key.

Lecturas relacionadas

• Coste de Claude Sonnet 5.5: cuánto cuesta el modelo frente a Sonnet 5
• Controles de razonamiento de los LLM: los ajustes de razonamiento que sí aceptan los modelos Claude más recientes
• Brecha de OpenCode: cómo proteger las claves de API: cómo limitar lo que se puede hacer con una clave filtrada
• Límites de peticiones en las API de LLM: cómo se contabilizan los límites por clave

← Volver al blog