Si Claude Code muestra top_p deprecated despues de pasar a Opus 4.7, no empieces cambiando de provider y tampoco asumas de inmediato que Claude Code se rompio por dentro. Lo que cambio de verdad fue el contract de request de Opus 4.7. Anthropic ahora rechaza top_p, temperature y top_k cuando llegan como valores no predeterminados. La pregunta util no es "por que se rompio Claude Code", sino "que capa sigue enviando esos sampling params viejos".
La ruta mas segura y mas rapida sigue siendo route-first. Primero confirma la version de Claude Code, luego la backend route real, despues limpia cualquier wrapper, plugin, proxy o config que siga inyectando esos campos, y solo entonces repite la misma ruta con la misma tarea. El fallback solo se vuelve razonable cuando version, route y cleanup ya estan comprobados y aun asi tu stack no puede dejar de enviar esos campos hoy.
Aqui conviene fijar un current fact antes de seguir. A fecha del 17 de abril de 2026, la documentacion de Claude Code sigue diciendo que Opus 4.7 necesita Claude Code v2.1.111+. Ademas, opus no significa lo mismo en todos los backends. En Anthropic API, Claude Code ya resuelve opus a Opus 4.7. En Bedrock, Vertex y Foundry, opus puede seguir siendo Opus 4.6 si no pineas 4.7 de forma explicita.
Por eso este tipo de error no hace perder tiempo porque falten consejos, sino porque es facil entrar en la rama equivocada desde el minuto uno. El route board de abajo existe para evitar precisamente eso.
Elige primero la rama correcta
top_p deprecated parece un error puntual, pero en realidad es un problema de ramas. La primera pregunta no es "que cambio exactamente en todo Opus 4.7", sino "estoy en una rama de version, de route, o de cleanup externo".
| Lo que ves ahora | Quien probablemente es el owner | Primer movimiento mas seguro | Que comprobar en la misma ruta | Cuando pensar en fallback |
|---|---|---|---|---|
Claude Code es mas viejo que v2.1.111 o el path local apunta a una instalacion vieja | Version del cliente first-party o drift de instalacion local | Actualiza Claude Code y confirma que de verdad arrancas el binary nuevo | Repite la misma tarea en la misma ruta despues del update | Incluso con version actual sigues viendo el mismo deprecated-parameter error |
| Crees que ya estas en Opus 4.7, pero la backend route o el alias no son los que piensas | Diferencia entre Anthropic API y el alias de Bedrock / Vertex / Foundry | Comprueba primero que opus realmente significa Opus 4.7 en esa ruta | Corrige o pinea y vuelve a probar la misma ruta | La route ya esta confirmada y el error no cambia |
Un wrapper, plugin, proxy o config sigue inyectando top_p, temperature o top_k | Capa externa de request shaping | Borra esos campos por completo, no los ajustes con otro numero | Repite la misma tarea con la request limpia | El stack de hoy no puede dejar de enviar esos campos |
| No puedes arreglar el stack ahora mismo pero necesitas que el workflow vuelva a funcionar | Compatibility lag fuera de la ruta first-party | Usa un bridge temporal solo despues de version, route y cleanup | Confirma que el fallback recupera la misma tarea y no cambia el contrato que pruebas | El fallback tambien falla o convierte el problema en otro mismatch |
El objetivo de la tabla no es listar todos los escenarios posibles, sino obligarte a seguir el orden con mejor relacion senal-esfuerzo. La mayoria del tiempo se pierde cuando el lector cambia de provider, route o proxy demasiado pronto y deja de poder verificar la ruta original.
Que cambio en Opus 4.7 y por que top_p ahora provoca 400
El migration guide de Anthropic lo deja bastante claro. En Opus 4.7, top_p, temperature y top_k con valores no predeterminados devuelven 400, y la ruta de migracion mas segura es omitir esos campos. La clave aqui es que ya no estamos ante un simple warning de deprecacion. Estamos ante un boundary nuevo de validacion del request.
En este punto muchos lectores toman el camino intuitivo y equivocado. Ven top_p deprecated y piensan que basta con poner un numero "mas seguro" o volver al default antiguo. Ese ya no es el movimiento correcto. El movimiento correcto ahora es dejar de enviar el campo.
Hay otra consecuencia mas amplia. Opus 4.7 desplaza el control desde los sampling params de bajo nivel hacia surfaces mas actuales como prompting mas claro y effort cuando existe. El trabajo de esta pagina no es ayudarte a conservar perillas viejas, sino a devolver tu request path al contract actual del modelo.
Si Claude Code en si es demasiado viejo o ni siquiera estas en una ruta soportada
Segun los docs de Claude Code revisados el 17 de abril de 2026, Opus 4.7 necesita Claude Code v2.1.111+. Por eso esta comprobacion tiene que ir primero. Si el cliente first-party ya esta fuera de la ventana de soporte, el resto del diagnostico se ensucia.
La comprobacion limpia aqui es corta:
- Mira la version real de Claude Code que estas ejecutando.
- Si es mas vieja que
v2.1.111, actualiza y confirma que el shell llama al binary nuevo y no a un path viejo. - Despues del update no cambies provider, env vars o proxy al mismo tiempo; repite la misma tarea en la misma ruta.
Ese tercer paso importa mas de lo que parece. Si haces el update y a la vez cambias la route, pierdes la mejor pregunta del diagnostico: si el current first-party client arreglo el problema por si solo o si simplemente escapaste hacia otra rama.
Si al final el root cause real era un install viejo o un binary path desfasado, lo mejor es seguir con la guia de instalacion de Claude Code. Esta pagina funciona mejor si se mantiene estrecha: exact deprecated-parameter recovery y no install troubleshooting general.
Si tu provider / alias route no es el que crees
Este punto se vuelve borroso en muchas paginas de fixes rapidos. Los current docs de Claude Code no cuentan la misma historia para todos los backends. En Anthropic API, opus ya es Opus 4.7. En Bedrock, Vertex y Foundry, el mismo opus puede seguir siendo Opus 4.6 si no pineas 4.7 de forma explicita.
Eso significa que dos lectores pueden decir "ya cambie a opus" y, sin embargo, estar probando contracts distintos. Uno esta realmente en 4.7 y por eso choca con la regla de deprecated params. El otro sigue en 4.6 y en realidad esta depurando otro mismatch disfrazado por una frase parecida.
La lectura segura del backend split es esta:
- Si estas en Anthropic API, no empieces suponiendo que el alias fallo; es mas probable que una capa externa siga enviando los fields retirados.
- Si estas en Bedrock, Vertex o Foundry y solo cambiaste
opus, confirma primero que de verdad llegaste a 4.7. - Si hay paneles intermedios, proxies o wrappers, no confies solo en la etiqueta visual. Confirma el target route real.
El objetivo de esta seccion no es volver paranoico al lector. Es evitar que arregle el contract equivocado.
Si un wrapper, plugin o config sigue enviando sampling params viejos
Cuando version y route ya estan confirmados, esta pasa a ser la rama mas probable. El current support de Claude Code no explica por si solo por que la misma ruta sigue mostrando top_p deprecated. La respuesta suele vivir en una capa externa.
Los primeros sitios que merece la pena revisar suelen ser:
- scripts locales alrededor de Claude Code
- provider adapters
- proxy middleware
- fragments de config copiados de ejemplos anteriores a Opus 4.7
El fix mas robusto aqui no es ajustar el valor. Es borrar el campo. temperature: 1 no es un parche especialmente seguro. Anthropic orienta la migracion hacia la omision, no hacia la sustitucion por otro numero.
Si despues de borrar esos fields todavia necesitas mas control sobre el comportamiento, desplaza ese control hacia prompting mas claro y effort donde exista. La meta no es reconstruir la superficie vieja, sino hacer que la request vuelva a encajar con el current model contract.
Si el trabajo real del lector ya se ensancho hacia "deberia seguir en 4.7 o volver a 4.6", entonces conviene derivar a Claude Opus 4.7 vs Claude Opus 4.6. Esta pagina solo quiere devolver a la vida la ruta rota.
Como verificar el fix y cuando el fallback pasa a ser razonable
La same-path verification marca la frontera de esta pagina. Da igual si acabas de corregir la version, la route o el cleanup: la verificacion debe volver a la misma tarea, al mismo backend y a la misma ruta. Si cambias de provider, de familia de modelos o de wrapper y ahi funciona, solo has demostrado que otra ruta existe.
El verification loop puede ser corto:
- Mantener el mismo backend y la misma tarea.
- Quitar los deprecated fields de la capa que realmente envia la request.
- Repetir una vez la misma ruta.
- Guardar la config limpia para que esos fields no vuelvan desde un template viejo o un middleware heredado.
El fallback no esta prohibido. Solo tiene que entrar tarde. Tiene sentido cuando ya se cumplen las cuatro condiciones:
- Claude Code esta en la ventana actual de soporte.
- La backend route esta confirmada.
- Sabes que fields hay que quitar.
- Y aun asi tu stack no puede dejar de enviarlos hoy.
En ese momento el fallback puede ser un bridge temporal: mantener una model route vieja por un rato o usar una capa de compatibilidad que quite los fields rechazados antes de llegar a Opus 4.7. Pero no es el fix principal. El mejor resultado a largo plazo sigue siendo alinear la request path con el current contract de Opus 4.7.
Si al final descubres que el exact 400 break real no tiene que ver con sampling params sino con la vieja rama de assistant-prefill removal, el sibling mas cercano es Claude Opus prefill error fix. Ambos casos pertenecen a la familia "request shape viejo choca con contract nuevo", pero no comparten el mismo root cause ni el mismo replacement workflow.
Frequently Asked Questions
top_p deprecated es realmente un bug de Claude Code?
No de forma simple. Claude Code es la symptom surface que el lector ve y busca. El hard break oficial vive en la validacion de requests de Opus 4.7. El current support de Claude Code existe; la pregunta real es que layer sigue enviando los fields viejos.
Por que opus no significa lo mismo en todos los backends?
Porque el current alias mapping cambia segun el backend. En Anthropic API, opus ya apunta a Opus 4.7. En Bedrock, Vertex y Foundry puede seguir apuntando a 4.6 si no pineas 4.7. Por eso route verification va antes del body cleanup.
No puedo dejar temperature o top_p con un valor mas seguro?
La ruta mas segura ahora es omitirlos. Anthropic empuja la migracion hacia la omision, no hacia la supervivencia con otro numero.
Que uso en lugar de esos sampling controls viejos?
Prompting mas claro y, cuando exista, effort. La idea no es recrear la superficie vieja con otros numeros, sino usar la que el current model family espera.
Cuando el fallback es razonable?
Solo despues de version, route y cleanup. Si el stack sigue sin poder parar esos fields, un bridge temporal puede tener sentido. Como primer movimiento, no.
The Working Rule
Si Claude Code muestra top_p deprecated en Opus 4.7, tratelo como un request contract mismatch y no como una excusa para cambiar de provider enseguida. Primero version, luego route, despues remove de fields viejos, y verificacion sobre la misma ruta. Si el stack sigue sin poder detenerlos, ahi si aparece el fallback.