Arreglar un fallo concreto
Su salto más grande respecto a Sonnet 5 está en el código. Un dump en una clase, una validación que no salta en un BAdI: tareas con un principio y un final claros.
Claude Sonnet 5.5
Rápido y muy capaz para el día a día
La mejor combinación de velocidad e inteligencia de la gama. Es más de un 30% más rápido que Sonnet 5 y cuesta hasta un 30% menos por tarea al mismo precio por token, porque gasta muchos menos. Donde brilla es en tareas bien acotadas: arreglar un fallo concreto, preparar un documento, una hoja o unas diapositivas cuidadas. Para el trabajo abierto que exige criterio sostenido, Anthropic sigue viendo a Opus 5.5 claramente por delante.
Lanzado el 28 de septiembre de 2026 · Guía revisada el 29 de septiembre de 2026
- ID en la API
claude-sonnet-5-5- Contexto
- 1M tokens
- Salida máxima
- 128K tokens
- Coste por API
- 2 $ / 10 $
- Velocidad
- Rápida
- Pensamiento
- Adaptativo
- Esfuerzo por defecto
- high (API) · medium (apps)
- Conocimiento hasta
- Junio 2026
Coste por API en dólares por millón de tokens (entrada / salida). Con una suscripción a Claude no se paga por token.
Para qué usarlo
Dónde rinde de verdad
Documentos, hojas y presentaciones cuidadas
Anthropic destaca que crea documentos, diapositivas y hojas de cálculo pulidos y que tiene buen ojo para el diseño. El informe semanal del proyecto o la hoja de seguimiento de pruebas.
Iterar rápido
Su velocidad lo hace cómodo para ir y volver: redactar la especificación técnica a partir de tus notas, ajustarla, volver a pedir.
Mejor otro modelo si…
- Para trabajo abierto que exige criterio durante mucho rato (una arquitectura, una auditoría), Opus 5.5.
- Para volumen muy alto y barato (clasificar miles de tickets), Haiku.
Cómo hablarle
5 claves para pedirle las cosas
- 1
Acota la tarea
Es más fuerte cuanto mejor definido está lo que pides. Di qué entra, qué no y qué significa terminado.
En vez de Mira a ver qué le pasa al programa de facturación.
Mejor El programa ZFACT_MENSUAL da un dump CONVT_NO_NUMBER al procesar clientes con IBAN extranjero. Encuentra la causa y propón el cambio mínimo. No toques el resto del programa.
- 2
Si quieres ideas o un plan, dilo
Ante una petición abierta puede ponerse a construir una presentación o un informe cuando tú solo querías opciones.
Prueba con Dame tres opciones para automatizar el cierre mensual, con pros y contras. No prepares nada todavía.
- 3
Si solo quieres el cambio, pídelo así
Tiende a añadir pruebas, documentación o pequeños ficheros de apoyo aunque no los pidas. A muchos equipos les viene bien; si no es tu caso, dilo.
Prueba con Cambia solo lo necesario para corregir el fallo. Si crees que algo más ayudaría, menciónalo al final en vez de hacerlo.
- 4
Pídele que compruebe lo que cambia con el tiempo
A veces responde de memoria cuando una búsqueda pillaría un dato que ha cambiado: lo que está permitido, lo que es obligatorio o lo que cuesta. Con licencias, precios o fechas de fin de mantenimiento de SAP, pide que lo verifique.
- 5
Exige una prueba real antes de dar algo por terminado
Con esfuerzo bajo a veces da un cambio por bueno sin ejecutar nada que lo compruebe.
Prueba con Antes de decir que está hecho, ejecuta una comprobación real del cambio: las pruebas unitarias, la activación sin errores o el propio programa con el caso que fallaba.
El mando principal
Cuánto esfuerzo pedirle
En las apps de Claude va en medium por defecto; por API, en high. En low o medium, en tareas largas, es más probable que se pare a preguntar antes de acabar: si te pasa, sube un nivel. Con esfuerzo bajo o medio supera la mejor nota de Sonnet 5 con una décima parte del coste en varias pruebas.
El esfuerzo decide cuánto piensa el modelo antes y durante la respuesta. Más esfuerzo suele dar mejor resultado en lo difícil, a cambio de tardar y costar más. En la app se elige en el selector del modelo; por API, con el parámetro effort.
Listo para copiar
Corregir un fallo acotado en ABAP
Tienes el dump, el código y quieres el cambio mínimo, ya.
Prompt para Sonnet 5.5
El programa [PROGRAMA] da el error [DUMP O MENSAJE] cuando [CASO QUE LO PROVOCA]. Te pego el análisis del dump de la ST22 y el código implicado. Quiero el cambio mínimo que lo corrija: 1. La causa, en dos o tres frases. 2. El código corregido, solo de las líneas que cambian, con una línea de contexto antes y después. 3. Cómo comprobarlo: el caso que fallaba y otro que funcionaba y debe seguir funcionando. No refactorices nada más. Si ves otro problema, menciónalo al final. Si la causa no se puede asegurar con lo que te paso, dime qué más necesitas.
Rellena lo que va entre corchetes. Funciona igual pegado en el chat que en un proyecto.
Si lo usas por API o con Claude CodeLo que cambia respecto a modelos anteriores
- Enviar temperature, top_p o top_k con un valor distinto del predeterminado devuelve un error 400.
- Para quitar el pensamiento inicial se usa thinking: between_tools (solo con esfuerzo high o inferior).
- Forzar el uso de una herramienta devuelve error.
- El texto entre llamadas a herramientas llega en bloques thinking: si tu interfaz solo muestra text, se quedará en silencio.
- Si pides JSON de algo que requiere calcular, añade "Piensa el problema antes de responder" o usa esfuerzo xhigh.