Saltar al contenido principal

Claude Sonnet 5: el nuevo modelo agente por defecto para Claude Code

· 10 min de lectura
Claude Dev
Claude Dev
Claude Dev

Anthropic publicó Claude Sonnet 5 el 30 de junio de 2026, posicionándolo como el modelo Sonnet más agentic hasta ahora y el nuevo modelo por defecto para usuarios Claude Free y Pro.

La propuesta es clara: Sonnet 5 lleva mucho del trabajo agentic que recientemente requería modelos Opus-class a una capa más barata, rápida y ampliamente disponible. Puede planear, usar navegadores y terminales, manejar tareas largas de coding y ejecutar adaptive thinking por defecto.

Para usuarios de Claude Code, eso hace que Sonnet 5 sea más importante que una actualización normal de modelo. Probablemente se convierta en la capa de ejecución por defecto para muchos equipos: no el modelo más fuerte que ofrece Anthropic, pero sí el que los desarrolladores usarán con más frecuencia.

La actualización no es sin fricción. Sonnet 5 tiene un tokenizer nuevo, cambios de comportamiento en la API alrededor de thinking y sampling parameters, cyber safeguards en tiempo real y una historia de precios que es más barata que Opus por token, pero no siempre por tarea.

Qué lanzó Anthropic​

El post de lanzamiento de Anthropic describe Sonnet 5 como una mejora importante sobre Sonnet 4.6 en reasoning, tool use, coding y knowledge work. La compañía dice que reduce la brecha con Opus 4.8 manteniendo un precio más bajo.

Los detalles operativos importan:

  • Model ID: claude-sonnet-5.
  • Disponibilidad: por defecto para usuarios Free y Pro, disponible para Max, Team, Enterprise, Claude Code y Claude Platform.
  • Ventana de contexto: 1M tokens por defecto y como máximo.
  • Salida máxima: 128k tokens en la Messages API síncrona.
  • Precio: precio de lanzamiento de 2 dólares por millón de input tokens y 10 dólares por millón de output tokens hasta el 31 de agosto de 2026. Luego el precio estándar será 3/15 dólares.
  • Adaptive thinking: activado por defecto para Claude Code y API.
  • Cyber safeguards: safeguards de ciberseguridad en tiempo real activados por defecto, la primera vez en un modelo Sonnet-tier.

La posición práctica es: Sonnet 5 no intenta reemplazar Fable o Mythos. Intenta hacer rutinario el trabajo agentic.

El feedback positivo: termina más trabajo​

El feedback positivo más fuerte es consistente entre citas oficiales de partners y primeras pruebas de medios: Sonnet 5 es mejor completando trabajos de varios pasos, no solo respondiendo a un prompt.

Los early access partners de Anthropic describen mejoras en sustained coding, debugging, seguimiento de convenciones, brownfield code y pull requests completados con pruebas. El patrón útil no es "escribe texto más bonito". Es "sigue trabajando, verifica más y llega a un resultado terminado con menos empujones".

La prueba práctica de TechRadar llegó a una conclusión similar fuera del coding. En chat normal, Sonnet 5 no se sintió radicalmente distinto de otros asistentes. Cuando se le pidió terminar trabajos, como planear un viaje o construir un household budget tracker, Claude se sintió más organizado alrededor de completar la tarea.

Eso importa para Claude Code. Los mejores casos de uso de Sonnet 5 no son snippets de un solo turno, sino workflows como:

  • investigar un bug, escribir un test de reproducción, arreglarlo y verificar;
  • migrar un módulo preservando convenciones del proyecto;
  • inspeccionar una codebase desordenada y producir un plan por etapas;
  • usar terminal y browser tools para reunir evidencia;
  • producir un artefacto, revisarlo y mantener coherente la salida.

Ahí es donde Sonnet 5 debería superar a Sonnet 4.6 en trabajo diario de desarrollo.

Benchmarks: Más fuerte, pero todavía no Opus​

La cobertura pública repite dos señales benchmark útiles.

TechRadar reporta el score de Anthropic en Terminal-bench 2.1 agentic coding en 80,5% para Sonnet 5, frente a 67% para Sonnet 4.6. ITPro reporta 63,2% en SWE-bench Pro para Sonnet 5, frente a 58,1% para Sonnet 4.6 y 69,2% para Opus 4.8.

La forma es clara:

  • Sonnet 5 es una mejora real sobre Sonnet 4.6.
  • Opus 4.8 sigue siendo más fuerte en las tareas de coding más difíciles.
  • Sonnet 5 puede igualar o acercarse a Opus 4.8 en algunas tareas con effort alto.
  • El valor principal es flexibilidad costo-rendimiento, no calidad frontier absoluta.

La documentación de Anthropic también enfatiza curvas costo-rendimiento a distintos effort levels en BrowseComp y OSWorld-Verified. La idea importante no es un número único de leaderboard. Es que los equipos ahora pueden ajustar effort y costo en un modelo Sonnet-class en vez de saltar directo a Opus.

El costo oculto de migración: cambiaron los tokens​

El mayor detalle de implementación es el nuevo tokenizer.

Anthropic dice que el mismo texto de entrada produce aproximadamente 30% más tokens en Sonnet 5 que en Sonnet 4.6, con variación según el contenido. Eso no cambia la forma de la API, pero sí cambia los presupuestos.

Esto afecta:

  • token counts en logs;
  • economía de prompt cache;
  • límites de max output;
  • planificación de context window;
  • estimaciones de costo para prompts equivalentes;
  • comparaciones de eval contra Sonnet 4.6.

Así que el precio de lanzamiento no es toda la historia de costo. Aunque el precio estándar por token siga siendo 3/15 dólares, el mismo workload puede usar más tokens. Los equipos deberían recontar prompts bajo Sonnet 5 antes de asumir que la migración es cost-neutral.

Cambios de API que los desarrolladores deben notar​

Sonnet 5 es drop-in replacement solo si tu código evita configuraciones deprecated o unsupported.

Los docs señalan tres cambios:

  1. Adaptive thinking está activado por defecto. Requests que no tenían campo thinking en Sonnet 4.6 ahora corren con adaptive thinking. Para apagarlo, pasa thinking: {type: "disabled"}.
  2. Manual extended thinking fue eliminado. thinking: {type: "enabled", budget_tokens: N} devuelve error 400. Usa adaptive thinking con el parámetro effort.
  3. Sampling parameters ya no se aceptan. temperature, top_p o top_k no default devuelven error 400. Usa instrucciones del system prompt para guiar el comportamiento.

Para usuarios de Claude Code, esto significa auditar wrappers viejos y agent harnesses personalizados antes de cambiar model IDs. Una actualización de modelo puede convertirse en bug de producción si el cliente sigue enviando parámetros obsoletos.

Feedback de seguridad: mejor que Sonnet 4.6, no tan fuerte como Opus​

Anthropic dice que Sonnet 5 tiene menores tasas de hallucination y sycophancy que Sonnet 4.6 y mejores resultados en agentic safety. También es más probable que rechace malicious requests y resista hijacking estilo prompt injection.

Pero la compañía también dice que Sonnet 5 todavía muestra tasas más altas de misaligned behavior que Opus 4.8 y Claude Mythos Preview en su automated behavioral audit.

La historia cyber también es específica. Sonnet 5 no fue entrenado deliberadamente para cybersecurity work. Puede hacer tareas cyber rutinarias y no dañinas, pero en evaluaciones cyber peligrosas rinde mucho peor que Opus 4.8 y Mythos 5. Aun así, como es más fuerte que Sonnet 4.6, Anthropic lo lanzó con real-time cyber safeguards activados por defecto.

Para equipos de seguridad, la lectura práctica es:

  • usar Sonnet 5 para ingeniería normal y trabajo defensivo rutinario;
  • esperar refusals en prompts cyber prohibited o high-risk;
  • usar Opus 4.8, con el acceso correcto, para cybersecurity work que necesite guardrails reducidos;
  • registrar stop_reason: "refusal" porque los refusals pueden llegar como respuestas HTTP 200 exitosas.

Reacción externa temprana: el modelo por defecto es la historia​

Axios enmarcó Sonnet 5 como un movimiento para llevar AI agentic al trabajo cotidiano manteniendo un perfil de riesgo inferior a Opus, Fable y Mythos. Esa es la lectura correcta.

Sonnet 5 importa porque cambia el default. Si usuarios Free y Pro, usuarios de Claude Code y desarrolladores de plataforma reciben un modelo Sonnet más agentic, los agent workflows dejan de ser un premium edge case y se vuelven la experiencia normal de Claude.

El riesgo es que los usuarios sobreestimen la autonomía. El hands-on de TechRadar fue positivo, pero señaló que todavía se necesitaba supervisión humana para decisiones, revisión, reservas, uploads y ejecución final. Sonnet 5 se acerca más al trabajo terminado, pero no reemplaza la review.

Para este sitio, el framing útil es simple:

Sonnet 5 es el modelo que deberías probar primero para automatización diaria con Claude Code, pero no el modelo en el que deberías confiar a ciegas.

Checklist de adopción en Claude Code​

1. Actualiza el model ID​

Mueve workloads de prueba de:

claude-sonnet-4-6

a:

claude-sonnet-5

Hazlo primero en una rama o entorno staging. No cambies el modelo por defecto en producción sin repetir tus evals.

2. Elimina parámetros API obsoletos​

Busca en tu codebase:

  • temperature
  • top_p
  • top_k
  • thinking: {type: "enabled"}
  • budget_tokens

Elimina sampling parameters no default y migra controles manuales de thinking a adaptive thinking más effort.

3. Recuenta tokens​

No reutilices presupuestos de Sonnet 4.6. Recuenta tus prompts más grandes, prefijos cacheados y sesiones típicas de Claude Code bajo Sonnet 5.

Presta atención a:

  • grandes resúmenes de repos;
  • planes generados;
  • logs pegados en el prompt;
  • resultados largos de herramientas;
  • ajustes de max output cercanos a la longitud esperada.

4. Define effort explícitamente​

La política más segura es hacer de effort una decisión por tarea:

  • medium para ediciones y explicaciones rutinarias;
  • high para tareas normales de Claude Code donde la corrección importa;
  • xhigh para debugging difícil, migraciones y agent runs largos.

No trates high effort como calidad gratis. Cambia latencia y uso de tokens.

5. Mantén Opus en el routing mix​

Sonnet 5 debería volverse default para muchos workflows, pero no todos.

Mantén Opus 4.8 disponible para:

  • high-risk refactors;
  • security-sensitive reviews;
  • decisiones de arquitectura ambiguas;
  • tareas donde perder un edge case sea caro;
  • review final de grandes cambios generados por Sonnet.

El patrón práctico es Sonnet para ejecución, Opus para escalación.

Conclusión​

Claude Sonnet 5 es un lanzamiento más grande de lo que parece porque mueve comportamiento agentic más fuerte al tier de modelo que la mayoría de equipos usará todos los días.

No es el nuevo modelo Claude top-end. Es el nuevo workhorse por defecto.

Para usuarios de Claude Code, el movimiento correcto es adoptarlo deliberadamente:

  • benchmarkearlo contra Sonnet 4.6 en tus tareas reales;
  • retunar token budgets para el nuevo tokenizer;
  • eliminar parámetros API no soportados;
  • medir costo por effort level;
  • conservar Opus 4.8 para escalaciones;
  • observar cyber-safeguard refusals en logs.

Si Sonnet 4.6 era la baseline práctica anterior y Opus 4.8 era la power tool, Sonnet 5 intenta devolver más de ese poder al workflow cotidiano. Por eso merece una migración cuidadosa, no un cambio de default a ciegas.

Fuentes revisadas​