Prompting Claude Opus 5.5: guía para founders y devs

Por qué Opus 5.5 cambia las reglas del prompting

Claude Opus 5.5 es el primer modelo de la familia 5.5 de Anthropic y llega con un cambio incómodo para muchos equipos: ya no puedes apagar el "thinking" como en Opus 5. En su lugar, Anthropic introduce adaptive thinking siempre activo y un único control, effort level, para calibrar cuánta razonamiento dedica el modelo a cada turno. La guía oficial de prompting publicada por Anthropic el 22 de septiembre de 2026 (TechRepublic) deja clara la consecuencia práctica: si copias los prompts de Opus 5 sin revisarlos, los turnos se vuelven más largos y más caros.

En precio, Opus 5.5 cuesta US$4 por millón de tokens de entrada y US$20 por millón de salida en el API estándar, un 20% menos que Opus 5. La lectura de caché cae 60% a US$0,20 por millón, que es donde se juega la mayor parte de la factura de cualquier agente que trabaja con código o documentos largos (MacObserver). En modo Fast — hasta 2,5× más rápido — los precios suben a US$8 y US$40 por millón, y solo tiene sentido cuando la latencia es el cuello de botella.

Sobre benchmarks: Opus 5.5 alcanza 66,4% en Terminal-Bench 4.0 frente a 57,9% de GPT-6 Astra, y 1846 Elo en GDPval-AA v2.1 contra 1542 del modelo de OpenAI. En coding agentico es donde la diferencia se nota más: un tester de GitHub reportó que en VS Code resolvió más tareas de terminal que Opus 5 en menos de la mitad de pasos (SiliconANGLE).

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

¿Qué cambia respecto a Opus 5 en el prompting?

El documento oficial de Anthropic parte de una premisa que conviene leer antes de migrar: los prompts de Opus 5 funcionan, pero arrancan en un punto distinto. La nueva variable es el nivel de esfuerzo, y cada nivel de Opus 5.5 no gasta la misma cantidad de razonamiento que el equivalente de Opus 5. Por ejemplo, según las pruebas de Anthropic, Opus 5.5 en medium iguala o supera a Opus 5 en high en coding y knowledge work, y low se acerca a high a un costo mucho menor.

Esto obliga a tres ajustes inmediatos:

Fija el effort explícitamente. Medium es el default en Opus 5.5; Opus 5 default era high. Si dejas el valor heredado, los turnos consumen más tokens de salida.
Sube el max_tokens a 128.000 para turnos largos. El razonamiento cuenta hacia max_tokens aunque no te llegue como bloque de texto. Un límite dimensionado para Opus 5 con thinking apagado puede cortar respuestas agenticas a mitad de camino.
No cambies el effort de arriba abajo entre requests, porque invalidas el prompt cache. Para variar el esfuerzo en una sola vuelta sin romper el caché, usa un cambio de effort por mensaje en beta.

En pruebas internas de Anthropic, Opus 5.5 mantuvo el ritmo en auditorías multi-hora y migraciones de bases de código completas, con menos tokens y pasos que Opus 5 — exactamente el caso de uso donde el prompting fino paga.

¿Cuándo ajustar el effort level (y cuándo no)?

Anthropic recomienda empezar en medium y medir con tus propias evals, no heredar el setting de Opus 5. Si en testing baja la calidad, sube a high. Si lo que quieres es gastar menos, baja el effort antes de añadir instrucciones tipo "responde directo", porque el control paramétrico es más fiable que el prompt. Reservar xhigh y max solo para tareas donde ya mediste una ganancia de calidad.

Tres situaciones concretas donde calibrar cambia la factura:

Agentes unattended en tareas largas. Un turno agentico que termina con texto en lugar de una tool call (stop_reason: "end_turn") no significa que el trabajo esté hecho. Mantén un checklist persistente (to-do tool o archivo) y, si quedan ítems abiertos, dispara un mensaje corto pidiendo continuar. Tras dos o tres continuaciones automáticas, corta y revisa para no quedarte en bucle.
Harnesses multi-agente. Opus 5.5 responde bien a presupuestos de tiempo. Pásale en cada mensaje el elapsed contra el budget (elapsed 340s / 1200s) y un poco de margen arriba, y suele terminar antes del límite. Para un stop duro, mantén tu timeout propio: el budget es consultivo.
Chat en producción. Si tu system prompt contiene "piensa cuidadosamente antes de responder", bórralo para Opus 5.5; el modelo decide solo cuánto pensar y effort ya controla el resto. En multi-turno, añade dos líneas para que no reescriba respuestas previas y sume latencia en cada follow-up.

Cómo migrar prompts que se diseñaron con thinking apagado

Si tu integración con Opus 5 corría con thinking: {"type": "disabled"}, la guía de Anthropic lista cuatro cambios que van juntos:

Arranca en low effort y mide. En low el razonamiento se mantiene corto; mide latencia y calidad sobre tu tráfico real y sube a medium si cae la calidad.
Elimina instrucciones que pedían razonamiento escrito en la respuesta. Opus 5.5 puede declinar con reasoning_extraction si le pides reproducir su razonamiento en el texto. Lee el razonamiento desde bloques de thinking con display: "summarized".
Re-testea las mitigaciones para thinking off. Lo de "permite hablar antes de un tool call", "qué hacer cuando ninguna tool encaja" y "sin tags internos" eran arreglos para artefactos de Opus 5 cuando el razonamiento estaba apagado. Con thinking siempre activo, probablemente ya no los necesitas.
Lee la respuesta por tipo de bloque. No asumas que el primer bloque es texto. Con display: "omitted" (el default), un bloque de thinking puede llegar con thinking vacío.

Visual inputs y frontend: dos detalles que casi nadie pule

Opus 5.5 lee gráficos, diagramas y capturas con más precisión que Opus 5 sin herramientas extra: en pruebas de Anthropic, incluso en el effort más bajo leyó valores de gráficos densos mejor que Opus 5 en el más alto, usando una fracción de los tokens de salida. Para inputs muy densos como planos técnicos, sigue ayudando subir la resolución y darle herramientas de procesamiento de imagen (PIL, OpenCV en un contenedor); sin herramientas, subir el effort ayuda con dibujos técnicos pero poco con gráficos.

En frontend, Opus 5.5 recurre a un set de defaults reconocibles (fondo crema, cursivas en titulares, etiquetas monoespaciadas, botones en pastilla, "01/02/03" numerados). Una instrucción genérica tipo "evita el look genérico de IA" solo cambia un default por otro. Funciona mejor nombrar los patrones que no quieres — como en el ejemplo de la guía: "No uses fondo crema u off-white, palabras en cursiva como acento en titulares, etiquetas tipo 01/02/03, labels monoespaciadas ni botones en pastilla" — y luego iterar mirando qué quedó en el primer render.

Resistir inyección de prompt en contenido pegado

Opus 5.5 mejora la resistencia a inyección indirecta (instrucciones que llegan dentro de tool results, páginas web o capturas). Para contenido que el usuario pega desde fuera, la guía pide envolver cada bloque pegado con un par de tags que compartan un ID aleatorio corto, y añadir al system prompt una nota explicando que ese contenido puede contener instrucciones ajenas. Es solo una capa: trátala junto al resto de defensas de inyección, no como sustituto.

¿Qué significa esto para tu startup?

Si ya corres Opus 5 en producción, la migración es barata pero no gratis. El ajuste que más factura mueve es revisar el effort default (no heredar el de Opus 5) y subir max_tokens para turnos agenticos largos. El que más cuesta dejar sin hacer es el de los checkpoints de avance en agentes unattended: sin ellos, un agente que termina con un texto-report se detiene y deja trabajo a medias.

Tres acciones concretas para esta semana:

Audita el effort por producto, no por prompt. Mide latencia, costo por tarea completada y tasa de retries para cada flujo agentico, y asigna effort por tipo de tarea (research exploratorio en medium, generación de código compleja en high, clasificación o extracción en low).
Migra el harness agentico al patrón checklist + continuación explícita para unattended runs, y pon un tope de 2-3 continuaciones automáticas antes de pausar para revisión humana.
Prueba cache reads a US$0,20/M sobre tu workload real. Si repites contexto en más del 30% de las llamadas, el ahorro del 60% en caché suele superar con creces la optimización de prompt.