Claude Opus 5.5: usos, prompts y niveles de esfuerzo

Claude Opus 5.5 merece una prueba cuando el trabajo exige entender un sistema existente, realizar cambios relacionados y comprobar el resultado. Empieza con una tarea acotada y esfuerzo medium. Proporciona el código o los documentos pertinentes, una definición explícita de terminado y una forma de demostrar el éxito. Aumenta el esfuerzo cuando puedas señalar qué faltó en el primer intento, no simplemente porque exista un nivel superior.

Esta guía explica dónde Opus 5.5 resulta prometedor, cómo encargarle trabajo y cómo evitar pagar por una entrega impresionante que no resuelve la necesidad real. Los flujos que proponemos son recomendaciones, no resultados de un benchmark independiente realizado por Wavect.

¿Por qué está generando entusiasmo Opus 5.5?

Anthropic presentó Opus 5.5 el 22 de septiembre de 2026, destacando mejoras en trabajos prolongados, comunicación y costes. Su reducción del 40% en el coste por tarea es una medición del proveedor frente a Opus 5, no un ahorro universal. Consulta las pruebas publicadas en el lanzamiento.

También hay entusiasmo de primera mano fuera del anuncio. El equipo de Every con acceso anticipado describió una mejor colaboración en programación y creatividad, pero también entregas incompletas y trabajo adicional innecesario. Estas observaciones explican parte del interés; no son una encuesta representativa de desarrolladores. Lee la experiencia de Every y su declaración sobre el acceso anticipado.

Nuestra interpretación: el atractivo no consiste únicamente en obtener una respuesta mejor. Consiste en reducir la fricción entre una petición ambigua y un resultado que se pueda revisar. Eso importa cuando un desarrollador necesita un cambio evaluable, no otra explicación sobre cómo hacerlo.

El identificador de la API es claude-opus-5-5, con una ventana de contexto documentada de un millón de tokens. La capacidad del modelo y los archivos que una aplicación le proporciona son cosas distintas. Seleccionarlo no le concede acceso automático a tu repositorio ni a los sistemas internos. Consulta las especificaciones del modelo.

¿Para qué tareas conviene utilizar Opus 5.5?

Prioriza trabajos cuya calidad dependa de conectar pruebas entre archivos, pasos o fuentes. La guía específica de Anthropic destaca programación a nivel de repositorio, revisión de código, trabajo documental e información visual. La tabla es nuestro punto de partida propuesto, no una clasificación medida. Consulta la guía de instrucciones para Opus 5.5.

Utiliza la misma estructura en todos los encargos: resultado, información disponible, límites, pruebas y condición de parada. Estos cinco elementos permiten revisar la tarea sin prescribir cada paso de implementación. Buscamos libertad suficiente para resolver el problema y poca ambigüedad sobre qué significa resolverlo.

¿Cómo refactorizar con Opus 5.5 sin cambiar el comportamiento?

Convierte la conservación del comportamiento en una entrega, no en una nota al margen. Para migrar una dependencia, pide primero un inventario de sus consumidores y obligaciones de compatibilidad. Después autoriza una parte representativa. Esa parte debe establecer el patrón que seguirán los demás cambios.

La documentación de Claude Code recomienda verificaciones ejecutables: tests, compilaciones y comparaciones de capturas. Consulta su flujo de verificación.

Un buen encargo es «hacer que la exportación de facturas pase por el adaptador existente sin cambiar las filas exportadas», no «modernizar la facturación». El primero tiene un límite y un resultado observable. El segundo invita a tomar decisiones arquitectónicas ajenas al objetivo.

Refactoriza la exportación de facturas para utilizar nuestro adaptador existente.
Lee primero las instrucciones del repositorio, el adaptador y los tests de exportación.
Antes de editar, enumera los consumidores y comportamientos que deben conservarse.

Mantén las interfaces públicas, el orden de las filas, el redondeo y los errores.
No cambies el esquema de datos, las versiones de dependencias ni formatos ajenos.
Implementa una ruta representativa y ejecuta los tests existentes pertinentes.
Añade un test de regresión donde la cobertura no proteja el contrato.

Entrega el diff, los comandos realmente ejecutados, sus resultados y los riesgos.
Pide autorización si conservar el comportamiento exige modificar el contrato público.
No hagas merge ni despliegues.

Protege la salida de referencia fuera del área que el agente puede modificar. De lo contrario, una implementación cambiada y una expectativa de test cambiada pueden coincidir y, aun así, incumplir el requisito original. El agente puede proponer actualizar una referencia, pero su aceptación debe ser una decisión separada.

¿Dónde ayuda Opus 5.5 en depuración y revisión de código?

Pídele investigar explicaciones alternativas, no producir directamente un arreglo plausible. ¿Qué observación permitiría distinguir una transición de estado incorrecta de un reintento ausente? ¿Cómo separar un problema de autorización de una dependencia no disponible? A menudo, la entrega más valiosa es un test que falla acompañado de una corrección pequeña.

La configuración Standard de CodeRabbit detectó 11 problemas OSS que su combinación de modelos de producción omitió, pero no detectó nueve que esa combinación encontró y utilizó más tokens. Standard es una configuración de la cadena de revisión, no un nivel de esfuerzo API. Conviene probar cobertura complementaria. Consulta la metodología de CodeRabbit.

Sonar informó de un 87,7% de tests superados por Opus 5.5 High frente al 88,6% de Opus 5 Thinking en 544 tareas Java ejecutables. Su análisis más amplio también observó menos código generado. Es otro trabajo con otra configuración; no prueba ni refuta por sí solo las mejoras en repositorios. Lee la evaluación original de Sonar.

Investiga por qué repetir una petición de checkout a veces crea un segundo pedido.
Usa únicamente el repositorio facilitado, logs anonimizados y datos sintéticos.
No contactes con producción ni modifiques pedidos reales.

Traza la petición, las transiciones de estado y la ruta de persistencia.
Propón dos causas plausibles y las pruebas que permitirían distinguirlas.
Reproduce la causa respaldada en un test local antes de editar la implementación.
Aplica el arreglo mínimo y prueba peticiones repetidas, concurrentes e interrumpidas.

Separa los hallazgos confirmados de las sospechas.
Para cada hallazgo confirmado, incluye archivos, reproducción e impacto.
Excluye las preferencias de estilo de la lista de defectos. No despliegues.

Para una prueba de revisión, proporciona al candidato y al revisor actual el mismo diff congelado y el mismo contexto. Mantén separados sus hallazgos hasta evaluarlos. Mide defectos confirmados, falsas alarmas y tiempo humano de revisión. Una lista más larga de comentarios no demuestra por sí misma mayor cobertura ni peor rendimiento.

¿Cómo obtener un frontend útil y no solo una maqueta atractiva?

Encarga a Opus 5.5 un recorrido pequeño pero completo: abrir una factura, corregir un error de validación y descargar el documento final. Especifica qué componentes y variables del sistema de diseño debe reutilizar. Exige estados de error, vacío y carga, no únicamente la captura que presenta bien la idea.

Nuestro flujo de sistema de diseño para Claude Code separa referencias visuales aprobadas, reglas de implementación y ejemplos reutilizables. Proporciona ese contexto antes de pedirle al modelo una dirección visual nueva.

Implementa el recorrido de detalle de factura con nuestro sistema de diseño actual.
Lee primero la referencia aprobada, las reglas y el componente existente más cercano.
Conserva rutas, contrato API, tipografía y variables de espaciado.

Cubre éxito, carga, vacío, error de validación y error del servidor.
Utiliza datos sintéticos. No inventes una integración backend funcional.
Comprueba el recorrido renderizado a 390 px y 1440 px, incluida navegación por teclado.
Compara las capturas con la referencia aprobada y corrige diferencias no deseadas.

Entrega archivos modificados, comprobaciones de interacción y ubicación de capturas.
Identifica todo lo simulado o no verificado. No declares el recorrido listo para
producción hasta superar las comprobaciones reales de integración y aceptación.

Las anchuras son criterios de ejemplo, no recomendaciones oficiales de Opus. Sustitúyelas por la cobertura real de dispositivos de tu producto. Cuando el agente no tenga acceso al navegador, debe indicarlo y dejar pendiente la comprobación visual, no afirmar que inspeccionó la interfaz.

¿Cómo utilizar Opus 5.5 para investigación y documentos de negocio?

Pide un registro de fuentes antes de una recomendación pulida. Un registro útil vincula cada afirmación relevante con su fuente, fecha y ubicación. Haz que identifique contradicciones y datos ausentes antes de que desaparezcan dentro de una redacción convincente.

Por ejemplo, un equipo que compara dos integraciones necesita límites documentados, costes de cambio y supuestos pendientes. No necesita una puntuación inventada que disimule la falta de pruebas. Conserva la distinción entre lo que dicen las fuentes y lo que recomienda el autor.

Prepara un informe de decisión de dos páginas con los documentos de integración.
Entrega el informe antes de crear diapositivas opcionales o análisis adicionales.

Empieza por la decisión, las restricciones y la información que falta.
Compara las opciones usando capacidades respaldadas y supuestos explícitos.
Para cada afirmación factual relevante, registra fuente, fecha y página o sección.
Muestra fórmulas y valores de entrada de todas las cifras calculadas.
Marca como desconocido cualquier valor no disponible; no lo estimes en silencio.

Termina con el siguiente experimento reversible y sus criterios de aceptación.
No contactes con proveedores, envíes mensajes ni publiques el documento.
Entrega el informe, el registro de fuentes y las preguntas pendientes.

Cuando haya capturas o gráficos densos, aporta los datos originales cuando estén disponibles y pide distinguir valores leídos de valores calculados. Para una entrega de marca, proporciona la plantilla real y prohíbe logotipos alternativos o datos de marca inventados. Revisa el archivo terminado, no solo la descripción del modelo.

¿Cómo mantener una sesión larga de Opus 5.5 centrada en el objetivo?

Define una secuencia de entregas, no un permiso para seguir mejorando indefinidamente. Recomendamos tres puntos de control: investigación con alcance acordado, resultado mínimo funcional y, finalmente, verificación y entrega. Cada punto debe producir algo que otra persona pueda inspeccionar.

Guarda las convenciones estables del repositorio en las instrucciones de proyecto admitidas por la herramienta. Claude Code documenta CLAUDE.md y la memoria automática, pero gestionar contexto no equivale a conservar un historial ilimitado de todo lo sucedido. Consulta el funcionamiento de la memoria de Claude Code.

Mantén un registro breve con el commit actual, decisiones aprobadas, trabajo pendiente y verificaciones. Indica a la siguiente sesión que compruebe el estado del repositorio antes de confiar en ese registro. Nuestra guía sobre contexto para agentes de programación aborda el problema general de información; aquí explicamos cómo aplicar el nuevo modelo dentro de ese flujo.

Divide el trabajo paralelo en partes realmente separables. Un agente puede revisar compatibilidad API mientras otro ejecuta los tests, con un coordinador que reconcilie resultados. Evita que varios agentes reescriban los mismos archivos sin una regla de responsabilidad. Más agentes no sustituyen una tarea coherente.

Los límites de gasto y permisos deben existir fuera del prompt. La documentación de costes de Claude Code explica visibilidad y controles, cuya disponibilidad depende del entorno de ejecución. Revisa los controles aplicables.

Nuestra regla operativa va más allá de «no superes el presupuesto»: utiliza un supervisor o límite del producto capaz de detener llamadas adicionales, no facilites credenciales de producción y exige aprobación para acciones externas. Un límite escrito de dinero o tiempo es una instrucción, no una barrera de seguridad.

Opus 5.5 medium frente a high: ¿qué nivel de esfuerzo elegir?

Empieza con medium y prueba un nivel superior frente a un fallo concreto. Opus 5.5 admite low, medium, high, xhigh y max; el valor predeterminado documentado es medium. Las etiquetas son específicas de cada modelo: nombres iguales no significan el mismo cómputo. Consulta la referencia de esfuerzo de Anthropic.

Antes de aumentar el esfuerzo, comprueba si falta un log, un esquema, datos de prueba o permiso para leer un archivo. Razonar más no proporciona un dato privado que el modelo nunca recibió. Cambia una variable cada vez y conserva la opción más económica cuando ambas superen las mismas comprobaciones.

¿Cómo seleccionar Opus 5.5 en Claude Code?

La documentación actual exige Claude Code v2.1.280 o posterior para Opus 5.5. Comprueba la versión instalada, actualiza mediante el procedimiento admitido y selecciona el modelo explícito. Los alias del proveedor y las restricciones de la organización pueden alterar la disponibilidad. Consulta la configuración de modelo y esfuerzo.

claude --version
claude update
claude --model claude-opus-5-5 --effort medium

El ejemplo corresponde a una configuración directa compatible de Claude. Utiliza el identificador de despliegue del proveedor cuando sea necesario, en lugar de copiar el identificador directo en cualquier nube. Comprueba la cabecera de sesión y el selector antes de registrar una comparación.

En una sesión interactiva existente, utiliza /model claude-opus-5-5 y /effort medium. Un identificador explícito resulta especialmente útil durante una prueba: el resultado no debería depender silenciosamente de cómo se resuelva un alias. Registra por separado la versión del cliente y cualquier modelo de respaldo.

En una aplicación de chat u otro editor, utiliza su selector y sus controles disponibles. Estos comandos de terminal son para Claude Code; los parámetros de API que aparecen a continuación no son necesariamente opciones que puedas pegar en una interfaz de chat.

¿Qué deben cambiar los usuarios de API antes de adoptar Opus 5.5?

Migrar no consiste únicamente en cambiar el nombre del modelo. Se rechazan la desactivación del pensamiento, los presupuestos manuales y la selección forzada de herramientas. También hay que conservar el historial de bloques de pensamiento, y cambia la herramienta anterior de uso del ordenador en Claude API y Google Cloud. Sigue la lista oficial de migración.

Para una pequeña comprobación de la API directa, guarda lo siguiente como opus55-request.json. La petición incluye su propia entrada y no presupone acceso a archivos locales. Es un ejemplo basado en documentación, no una llamada realizada para este artículo.

{
  "model": "claude-opus-5-5",
  "max_tokens": 4096,
  "thinking": { "type": "adaptive", "display": "summarized" },
  "output_config": { "effort": "medium" },
  "messages": [{
    "role": "user",
    "content": "Revisa este cambio propuesto: los reintentos crean un pedido nuevo antes de comprobar el identificador existente de la petición. Explica el riesgo y propone un test de regresión local. No afirmes haber inspeccionado un repositorio."
  }]
}

Con una clave configurada y una cuenta con saldo, esta petición genera cargos de API. No pegues las credenciales en el JSON ni las incluyas en un commit.

curl --fail-with-body --silent --show-error \
  https://api.anthropic.com/v1/messages \
  -H "x-api-key: ${ANTHROPIC_API_KEY:?Set ANTHROPIC_API_KEY first}" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  --data-binary @opus55-request.json

Un caso de diagnóstico poco evidente es el agente que parece callado entre llamadas a herramientas. Opus 5.5 devuelve esa narración en bloques de pensamiento, omitidos por defecto; display: "summarized" solicita resúmenes legibles. Este ejemplo no utiliza streaming. Conserva también llamadas, resultados y registros de acciones: los resúmenes no son una auditoría completa. Consulta los cambios en la respuesta.

Para salidas legibles por máquinas, distingue la validez del esquema de la finalización de la tarea. Los argumentos estrictos limitan la forma de una llamada; no garantizan que el modelo llame a una herramienta ni que el contenido sea correcto. Valida las acciones necesarias en tu aplicación. Revisa las garantías y límites de las salidas estructuradas.

¿Cuánto cuesta realmente Opus 5.5 por tarea?

Estas tarifas estándar de API directa están expresadas en USD por millón de tokens y se comprobaron el 24 de septiembre de 2026. No son precios de suscripción ni una promesa sobre la factura de otro proveedor. Consulta las tarifas actuales de Anthropic.

Para una carga inventada con 200.000 tokens de entrada sin caché, 100.000 de escritura de caché de cinco minutos, un millón de lectura de caché y 20.000 de salida, el cálculo es:

Opus 5.5: 0,80 + 0,50 + 0,20 + 0,40 = 1,90 USD.

Opus 5: 1,00 + 0,625 + 0,50 + 0,50 = 2,625 USD.

Supone aproximadamente un 27,6% menos para cantidades idénticas de cada tipo de token, no un 40%. Es aritmética, no un benchmark. Excluye herramientas, infraestructura, intentos adicionales, modificadores de precio y revisión humana. El consumo real puede variar entre modelos en cualquier dirección.

La caché de prompts reutiliza prefijos coincidentes que cumplen los requisitos; no es memoria permanente del proyecto. Coloca instrucciones estables y contexto reutilizable antes de los detalles variables, y comprueba el consumo de caché reportado en vez de suponer que toda repetición recibe descuento. Lee las reglas de coincidencia y facturación.

Fast mode plantea otra compensación: la versión preliminar de la API directa indica 8 USD de entrada y 40 USD de salida por millón de tokens. Se orienta a velocidad de generación, no a reducir obligatoriamente la duración completa de una tarea. Pruébalo donde la espera sea un problema medido. Consulta alcance y precios de Fast mode.

Para decidir la adopción, utiliza coste por tarea aceptada: gasto de modelos y herramientas en todos los intentos, más revisión y retrabajo, dividido entre tareas aceptadas. Mantén visible el tiempo de revisión aunque no lo conviertas a dinero. Una tarea rechazada también consume presupuesto.

¿Cuándo no conviene utilizar Opus 5.5?

No lo conviertas en la opción automática para una transformación determinista que un script ya resuelve, una tarea rutinaria que un modelo más económico supera de forma fiable o un trabajo cuya información no pueda compartirse con el servicio autorizado. Son criterios para elegir tareas, no afirmaciones de incapacidad del modelo.

Tampoco conviertas una respuesta convincente en el único control de lanzamiento para permisos, pagos o cambios destructivos. Define primero la comprobación independiente. Cuando no puedas inspeccionar el resultado, reduce la autoridad del agente o mantén su función como asesor.

Evita pedir un producto completo cuando la decisión de negocio siga abierta. Una persona debe resolver el problema del usuario, el alcance y los criterios de aceptación. Después, el agente puede implementar dentro de esas decisiones. Una actualización de modelo no decide qué necesitan los clientes.

¿Cómo evaluar Opus 5.5 en tu propio repositorio?

Realiza una prueba controlada pequeña antes de cambiar la opción predeterminada del equipo. Proponemos diez tareas históricas que incluyan refactorizaciones, errores reproducidos, cambios de interfaz y un informe basado en fuentes. Usa trabajos terminados cuyo resultado válido pueda reconocer un revisor, pero no incluyas sus soluciones en la entrada del agente.

Proporciona a Opus 5.5 en medium y a tu configuración actual el mismo estado inicial congelado, herramientas, permisos e instrucciones. Repite los casos difíciles: una sola ejecución puede engañar. Escala selectivamente los fallos a high; no mezcles configuraciones silenciosamente en un único resultado.

Elige la configuración que alcance el umbral de aceptación con un coste total adecuado. Conserva la anterior como alternativa ante regresiones. El resultado puede combinar Opus 5.5 para ingeniería exigente, un modelo pequeño para trabajo rutinario y aprobación humana para decisiones importantes.

El servicio de AI enablement de Wavect convierte el acceso a herramientas en flujos repetibles para equipos. El caso de Twinsoft AI es experiencia de implementación independiente, no un benchmark ni una afirmación de despliegue de Opus 5.5. Utiliza la guía de QA antes del lanzamiento para definir evidencias o plantea una prueba de agentes con tu repositorio real.

Fuentes, fecha y límites de esta guía

Revisión del 24 de septiembre de 2026, dos días después del lanzamiento. Consultamos documentación de Anthropic y las evaluaciones originales enlazadas. Este artículo es un análisis de fuentes con prompts y criterios propuestos, no un benchmark práctico de Wavect. No realizamos llamadas reales a la API, migraciones de producción ni experimentos de latencia para prepararlo.

Verifica disponibilidad, precios y requisitos del cliente antes de adoptarlo. Fija la configuración utilizada en la prueba y repite sus tareas de aceptación cuando cambie el modelo o el cliente.