Claude Code con top_p deprecated? Primero corrige la ruta de Opus 4.7, no cambies de provider

Si Claude Code muestra top_p deprecated al usar Opus 4.7, elimina los parámetros de muestreo de la petición que realmente recibe el modelo. En Anthropic Messages se llaman top_p, temperature y top_k; en Bedrock Converse, topP y temperature están dentro de inferenceConfig. No basta con borrar una opción de tu configuración si un adaptador la vuelve a añadir después.

Antes de cambiar nada, confirma el cliente que ha fallado, el proveedor y el identificador de modelo utilizado. Después modifica únicamente los campos rechazados y repite la misma tarea por esa misma conexión. Así podrás distinguir una reparación de un cambio a otro modelo que acepta un formato diferente.

La documentación de Anthropic en español indica que Opus 4.7 y versiones posteriores rechazan con HTTP 400 los valores no predeterminados de temperature, top_p y top_k, y recomienda omitirlos. Para Opus 4.7 en Bedrock, AWS especifica que esos tres controles no se admiten. No deduzcas de ello que 0, 1 o null funcionarán en tu conexión.

Localiza el error antes de tocar la configuración

El texto visible en Claude Code no identifica por sí solo quién añadió top_p. Puede proceder del servicio remoto, del SDK o de una capa que construye la petición. La diferencia determina dónde debes actuar.

Anthropic también documenta la retirada de estos argumentos en el SDK de Python v1 y posteriores, con la posibilidad de un TypeError. Esa es una condición documentada del SDK, no una comprobación de la versión que tienes instalada. Tampoco todos los HTTP 400 son errores de muestreo: el historial, las herramientas o las opciones de razonamiento pueden tener sus propias restricciones.

Guarda un diagnóstico breve sin credenciales ni contenido confidencial: versión del cliente que produjo el error, nombre del proveedor, operación utilizada, identificador exacto del modelo y nombres de los campos de muestreo presentes. Si tienes acceso autorizado al adaptador, inspecciona la estructura justo antes del envío, después de sus transformaciones. Una plantilla de entrada limpia no demuestra que la petición de salida lo esté.

Comprueba el modelo real: opus no equivale siempre a Opus 4.7

El alias opus es una selección que puede cambiar con el tiempo y según el proveedor. La configuración actual de modelos de Claude Code ya no permite usar como regla general el mapa de abril «Anthropic = 4.7; todos los proveedores de nube = 4.6». Para depurar este error necesitas el modelo que se envía, no solo la etiqueta del selector.

Anota el identificador o destino resuelto por tu conexión: un identificador de la API de Claude, un perfil de inferencia de Bedrock, un nombre de despliegue o el identificador correspondiente al proveedor. Un cambio de URL no demuestra que hayas cambiado de modelo, y un nombre de modelo aceptado por un proveedor no tiene por qué ser válido en otro.

En Claude Code, una elección mediante /model puede prevalecer sobre el modelo de arranque. La documentación también distingue la elección guardada con Intro o con /model <nombre> de la selección temporal mediante s en el selector. Si solo quieres una prueba de sesión, ten en cuenta esa diferencia antes de guardar un modelo como predeterminado. Aquí no necesitas cambiarlo para quitar parámetros: primero identifica el que ha fallado.

La referencia a Claude Code v2.1.111+ de la versión original de esta guía correspondía a la llegada de Opus 4.7 en abril. No es un mínimo universal para los modelos actuales. Comprueba el requisito del modelo seleccionado y cualquier mínimo impuesto por tu organización. Si el error es de versión del cliente, resuelve esa incompatibilidad por separado y conserva el mismo destino al comprobar el resultado; no atribuyas todos los fallos con top_p a una instalación antigua.

Quita los campos donde se construye la petición final

La modificación debe aplicarse después de incorporar los valores predeterminados de la capa que controla el envío. Si tu aplicación combina opciones globales, opciones del modelo y opciones del agente, borrar la primera copia puede dejar otra activa. Cuando no controlas el adaptador, documenta qué campo sigue enviando y busca una corrección específica de ese componente.

Anthropic Messages y el cuerpo nativo de Bedrock

En una petición nativa Messages, elimina top_p, temperature y top_k del nivel superior del cuerpo. No sustituyas el valor rechazado por otro. Por ejemplo, un cuerpo de Messages sin esos controles puede tener esta forma:

{
  "model": "claude-opus-4-7",
  "max_tokens": 1024,
  "messages": [
    {"role": "user", "content": "Devuelve tres pasos para revisar una función."}
  ]
}

Es un ejemplo del cuerpo, no una llamada completa con autenticación. Conserva el límite de salida que corresponda a tu tarea, las instrucciones y cualquier herramienta necesaria. Quitar controles de muestreo no requiere borrar max_tokens, stop_sequences, el historial ni las opciones admitidas de prioridad del servicio.

Bedrock también ofrece una invocación nativa de Claude con su propio formato: el ejemplo de AWS para Opus 4.7 utiliza anthropic_version: "bedrock-2023-05-31" dentro del cuerpo. No copies sin más el cuerpo de la API de Claude a cualquier operación de AWS: el identificador del modelo, los campos de versión y el lugar donde se pasan dependen de la operación utilizada.

Bedrock Converse: topP no se escribe top_p

En Converse, los controles básicos están en inferenceConfig. Para Opus 4.7, retira inferenceConfig.topP y inferenceConfig.temperature, conservando los controles válidos, como maxTokens o stopSequences cuando los necesites:

{
  "inferenceConfig": {
    "maxTokens": 1024,
    "stopSequences": ["FIN_DE_RESPUESTA"]
  }
}

Este fragmento solo muestra el bloque de inferencia; conserva también modelId, messages y los demás campos de tu petición. stopSequences termina la generación al encontrar una secuencia: no lo añadas si no forma parte de tu tarea.

Los campos específicos del modelo pueden ir en additionalModelRequestFields. La referencia de Converse incluye un ejemplo antiguo de Sonnet con top_k en ese bloque; explica dónde se coloca el campo, no que Opus 4.7 lo admita. Si tu adaptador lo envía allí para Opus 4.7, quítalo sin vaciar los demás campos del bloque. No muevas los controles rechazados a otro contenedor para intentar conservarlos.

Aunque el esquema genérico de InferenceConfiguration incluya topP y temperature como opcionales, eso no garantiza que todos los modelos los acepten. Para Opus 4.7 prevalece la restricción específica del modelo.

Ejemplo local: quitar controles sin modificar los datos de las herramientas

El siguiente código de Python trabaja solo con un diccionario en memoria. Úsalo en el punto donde tu adaptador ya haya construido el cuerpo final, solo después de confirmar que el destino es Opus 4.7 y que el formato coincide. No detecta modelos automáticamente ni envía una petición:

from copy import deepcopy


def quitar_muestreo_opus47(peticion, formato):
    limpia = deepcopy(peticion)
    if formato == "messages":
        for campo in ("top_p", "temperature", "top_k"):
            limpia.pop(campo, None)
    elif formato == "converse":
        inferencia = limpia.get("inferenceConfig", {})
        adicionales = limpia.get("additionalModelRequestFields", {})
        if not isinstance(inferencia, dict) or not isinstance(adicionales, dict):
            raise TypeError("Los bloques de inferencia deben ser objetos")
        for campo in ("topP", "temperature"):
            inferencia.pop(campo, None)
        adicionales.pop("top_k", None)
    else:
        raise ValueError("Formato no reconocido")
    return limpia


original = {
    "model": "claude-opus-4-7",
    "max_tokens": 1024,
    "top_p": 0.8,
    "messages": [{"role": "user", "content": "Revisa este esquema"}],
    "tools": [{
        "name": "guardar_medicion",
        "description": "Guarda una medición del usuario",
        "input_schema": {
            "type": "object",
            "properties": {"top_p": {"type": "number"}}
        }
    }]
}
limpia = quitar_muestreo_opus47(original, "messages")
assert "top_p" not in limpia
assert "top_p" in limpia["tools"][0]["input_schema"]["properties"]
assert limpia["messages"] == original["messages"]
assert limpia["max_tokens"] == original["max_tokens"]
assert "top_p" in original

No uses una eliminación recursiva de cualquier propiedad llamada top_p o temperature. Esas palabras pueden aparecer en un esquema de herramienta, en una medición o en datos del usuario y no ser controles del modelo. En el ejemplo, tools[].input_schema.properties.top_p se conserva deliberadamente.

El código y los casos sintéticos de ambos formatos se han comprobado de forma local; no se ha ejecutado el SDK ni una inferencia real. Si tu adaptador usa otro formato interno, corrige su conversión a los campos de salida documentados en lugar de aplicar esta función a un objeto desconocido.

Si ya borraste top_p y el error continúa

Busca una segunda incorporación del campo. Comprueba las opciones del agente, los valores predeterminados del adaptador, las variantes de modelo y cualquier plantilla que se mezcle al final. Sigue el campo hasta la última capa que puedes inspeccionar, sin registrar los mensajes completos ni los secretos del usuario.

Existe un caso público que muestra por qué importa revisar el envío final: en la incidencia 304 del ejemplo de procesamiento documental de AWS, el autor informó de un error con top_p en el flujo con agentes y Strands/ConverseStream aunque su configuración ya no contenía ese campo. El mantenedor comunicó una corrección en la versión 0.5.10 del ejemplo para detectar el modelo y omitir los parámetros en sus flujos.

Esa versión pertenece a esa aplicación de ejemplo. No es una versión de Claude Code ni prueba que cualquier adaptador, proxy o servicio haya corregido el problema. Úsala para reconocer el patrón «configuración limpia, petición todavía incorrecta», no como instrucción universal de actualización.

Cómo comprobar que has reparado el mismo flujo

La primera comprobación es estructural: justo antes del envío, los campos rechazados deben estar ausentes de sus contenedores. La segunda es funcional: la tarea debe completarse con el modelo y la conexión originales, conservando las herramientas y el formato de respuesta que necesitabas.

1. Mantén el proveedor, la operación, el identificador de modelo y la tarea que fallaron. Si cambiaste un componente, anota cuál.
2. Verifica que el adaptador no vuelve a insertar los controles después de tu modificación.
3. Cuando puedas realizar una prueba autorizada en tu entorno, repite la petición por esa misma conexión.
4. Comprueba el resultado completo: respuesta final, llamadas y resultados de herramientas si las había, y cumplimiento del formato solicitado.

Un HTTP 400 diferente indica que has llegado a otra validación; no demuestra que el flujo funcione. Una respuesta aceptada tampoco garantiza que las herramientas hayan terminado correctamente. Si el mismo parámetro sigue apareciendo, vuelve a su lugar de incorporación. Repetir una petición idéntica que el modelo rechaza por su estructura no corrige el cuerpo.

Qué puedes usar en lugar de top_p

Para orientar la respuesta, expresa en las instrucciones el objetivo, las restricciones y el formato esperado. Si el modelo admite output_config.effort, ese control permite ajustar el trabajo y la profundidad de la respuesta, con efectos sobre el uso de tokens, según la documentación de esfuerzo de Anthropic.

effort no es una sustitución numérica de top_p. No hay una conversión del tipo «top_p: 0.8 equivale a effort: high», ni una garantía de respuesta idéntica por usar cierto nivel. Elimina primero los campos incompatibles y después evalúa los controles admitidos con ejemplos representativos de tu tarea. No aumentes automáticamente el límite de salida ni actives opciones de razonamiento para reparar un error de muestreo.

Preguntas frecuentes

¿top_p deprecated significa que Opus 4.7 está retirado?

No. La retirada de un parámetro y la retirada de un modelo son cambios distintos. La tabla de estado de Anthropic consultada el 6 de octubre de 2026 mantiene Opus 4.7 y Opus 4.6 activos. Eso no confirma los permisos ni la disponibilidad de tu cuenta en un proveedor concreto.

¿Puedo poner top_p: 1 o temperature: 0 para evitar el error?

No lo tomes como una solución garantizada. Anthropic recomienda omitir los controles de muestreo incompatibles; AWS declara que Opus 4.7 no los admite. Quitar una clave no es lo mismo que enviarla con null, y un valor aceptado tampoco demostraría que la respuesta sea determinista.

¿Debo cambiar de proveedor si no puedo modificar el adaptador?

Puedes valorar temporalmente otro modelo o una conexión cuyo adaptador admita el formato necesario, siempre que esté disponible para tu cuenta y cumpla tu tarea. Antes, identifica qué controles añade el componente que falla. Un cambio de modelo o proveedor puede alterar herramientas, salida y comportamiento; prueba esos requisitos por separado. Que la alternativa funcione no demuestra que hayas reparado Opus 4.7 en la conexión original.

¿Basta con eliminar top_p del archivo de configuración?

Solo si el cuerpo final también queda limpio. Un valor predeterminado del SDK, adaptador o agente puede volver a introducirlo. Comprueba el campo en la estructura que se envía y conserva las propiedades homónimas que pertenecen a herramientas o datos del usuario.