Parámetro temperature en Claude Opus 4.7: elimínalo, no lo reajustes

Si Claude Opus 4.7 devuelve un 400 porque la solicitud todavía envía temperature, no empieces buscando otro valor. La primera corrección segura es eliminar ese campo del payload real que sale de tu sistema.

La misma regla aplica a top_p y top_k. El trabajo no consiste en adivinar un nuevo número de sampling, sino en encontrar qué capa sigue agregando campos antiguos: llamada SDK, adaptador de Bedrock, gateway, plugin de IDE, eval harness, preset o plantilla de retry.

El orden seguro es: eliminar los campos antiguos, confirmar que el final outbound payload está limpio, mover el control a prompt, schema, tests o effort cuando aplique, y repetir la misma ruta. Solo considera fallback cuando el stack actual no puede dejar de enviar esos campos.

Matriz rápida de corrección

Trata el fallo como depuración de request path antes de tratarlo como problema de proveedor.

La columna de verificación importa. Si cambias proveedor, modelo, prompt y wrapper a la vez, no sabrás qué arreglo funcionó.

Qué cambió en Opus 4.7

La guía actual de migración de Anthropic para Opus 4.7 indica que valores non-default de temperature, top_p y top_k devuelven 400. La ruta de migración segura es omitir esos campos.

Por eso temperature: 0 no es un parche correcto. Incluso antes, temperature 0 no era una garantía universal de salidas idénticas. En Opus 4.7, el campo forma parte de una forma de solicitud incompatible.

Después de reconocer el field name en logs, cambia la pregunta: no es tuning de temperature, es limpieza del request contract.

Corrige API y SDK directos

Si el campo está en tu código, elimínalo.

python
message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1200,
    temperature=0.2,
    top_p=0.9,
    messages=[{"role": "user", "content": "Refactor this function."}],
)

Después:

python
message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1200,
    messages=[{"role": "user", "content": "Refactor this function."}],
)

En TypeScript:

ts
const response = await anthropic.messages.create({
  model: "claude-opus-4-7",
  max_tokens: 1200,
  messages: [{ role: "user", content: "Summarize the incident." }],
});

Luego mira el body final, no solo el call site. Un helper compartido puede volver a añadir defaults, un gateway puede traducir campos OpenAI-compatible, y un retry puede reconstruir desde una plantilla vieja.

Para formato estricto, escribe un contrato de salida:

text
Return exactly one JSON object with keys "root_cause", "fix", and "verification".
Do not include prose outside the JSON.
If evidence is insufficient, set "root_cause" to "unknown".

Encuentra la capa de inyección

La versión difícil aparece cuando tu aplicación no menciona temperature, pero el proveedor lo recibe. Entonces debes inspeccionar la cadena completa.

Revisa:

• wrappers del SDK con generation defaults globales;
• gateways OpenAI-compatible que copian temperature al body Anthropic;
• adaptadores Bedrock que mezclan defaults de cuenta;
• plugins de IDE o presets de agente antiguos;
• eval harness que fija temperature para comparar runs;
• variables como MODEL_TEMPERATURE;
• middleware de retry que reutiliza un body stale.

No necesitas registrar secretos. Registra field names, model ID, route y si aparecen los campos antiguos.

Bedrock y rutas de proveedor

La model card de AWS Bedrock para Claude Opus 4.7 también indica que temperature, top_p y top_k ya no son soportados. Si falla por Bedrock, revisa el adapter antes de cambiar de proveedor.

Si tu pregunta real es si debes migrar de Opus 4.6 a Opus 4.7, usa Claude Opus 4.7 vs Claude Opus 4.6. Aquí el objetivo es recuperar la ruta ya elegida.

Qué reemplaza a temperature

No hay un reemplazo uno-a-uno. Divide el trabajo.

effort controla razonamiento y gasto de tokens. No lo presentes como temperature renombrado.

En una migración real conviene escribir la sustitución como trabajos de control, no como una lista de campos eliminados. El formato estable vive en schema, ejemplos, instrucciones negativas y validación. La longitud vive en max_tokens, prioridades y stop conditions. El razonamiento vive en effort solo si la ruta lo soporta. La variación controlada vive en pedir varias opciones con criterios, no en recuperar knobs antiguos. Esa separación evita que alguien vuelva a añadir temperature para "hacerlo más estable" después de que el hotfix pase.

El cambio también debe quedar visible para code review. Una nota útil dice: "para Claude Opus 4.7 no enviamos temperature, top_p, top_k; inspeccionamos el payload final después de adapters; reintentamos el mismo prompt en la misma ruta; usamos prompt contract o effort según el trabajo". Esa nota es mejor que "bajamos temperature a cero", porque explica qué se puede verificar y qué ya no pertenece al request.

Verifica antes de fallback

Verifica en la misma ruta:

1. Mismo modelo, proveedor, prompt y tarea.
2. Campos temperature, top_p, top_k eliminados.
3. Final outbound body limpio.
4. Un retry en la misma ruta.
5. Regression guard para que no vuelvan los defaults.

Fallback puede salvar una entrega, pero debe quedar marcado como puente: modelo antiguo temporal, gateway que elimina campos o pin de versión. La solución duradera es alinear el payload con Opus 4.7.

Antes de fallback, separa tres señales. Primero, el error original debe estar asociado a un request_id o log que muestre la ruta y los field names, sin secretos. Segundo, el retry limpio debe mantener model, provider, prompt y tarea. Tercero, debes saber qué capa agregaba el campo: SDK helper, gateway, Bedrock adapter, IDE preset o eval harness. Si falta una de esas señales, cambiar de proveedor solo oculta el bug.

La observabilidad también debe ser segura. No registres prompts completos, datos de usuario ni claves. Registra model ID, provider route, nombres de campos top-level, resultado del retry y owner del layer. Con eso puedes demostrar que el payload ya no contiene temperature, top_p ni top_k y puedes abrir una tarea concreta para impedir que el default vuelva.

Preguntas frecuentes

¿Se eliminó temperature por completo?

La frontera oficial habla de valores non-default. En ingeniería, omitir el campo es lo más seguro porque SDKs y gateways pueden tratar defaults de forma distinta.

¿Sirve temperature: 0?

No como migración. Para estabilidad usa prompt, schema, tests y same-route verification.

¿effort reemplaza a temperature?

No. effort regula razonamiento y tokens. Estilo y formato se controlan con prompt contract.

¿Bedrock falla por la misma razón?

Sí. Bedrock tampoco soporta esos sampling fields para Opus 4.7. Revisa el adapter y el final provider payload.

¿Es lo mismo que Claude Code top_p deprecated?

Comparte la frontera de sampling, pero Claude Code tiene checks propios de versión, ruta y preset. Usa Claude Code Opus 4.7 top_p Deprecated.

Regla de trabajo

Si Claude Opus 4.7 falla por temperature, no reajustes el número. Elimina el campo, encuentra la capa de inyección, mueve el control a prompt o effort, y verifica la misma ruta.