Claude Sonnet 4.6 (claude-sonnet-4-6) es la instantánea Sonnet que rompió el techo de 200k tokens. Un millón de tokens de ventana de contexto. Entrada de texto e imagen. El modelo de tier medio que, por primera vez en la familia Claude, hizo de las entradas muy largas una elección razonable sin pagar por el tier Opus.
El encuadre que mejor le aplica a esta instantánea: Sonnet 4.6 es el modelo al que se recurre cuando se quiere la fiabilidad y la postura de rechazo del estilo Sonnet, pero la carga de trabajo no encaja dentro de los 200k tokens. Es una franja de casos de uso más estrecha que la línea Sonnet general, pero es una franja que no tenía una buena respuesta antes de que esta instantánea saliera.
Qué aporta realmente la ventana de un millón de tokens
Un millón de tokens es suficiente para un expediente de resultados trimestrales completo, un monorepo de tamaño mediano o un hilo de conversación de varios meses. La línea de marketing es real. La pregunta práctica es la misma que aplica a todo modelo de contexto largo: ¿la calidad de atención se mantiene a lo largo del buffer, o el modelo pierde el rastro de los datos colocados al principio una vez que el final está lleno?
Sonnet 4.6 mantiene bien la atención pasadas las 200k tokens, que es el precipicio en el que tropezaba el resto de la línea Sonnet. Pasadas aproximadamente las 600k tokens se aprecia cómo la latencia se estira y los tokens por segundo en streaming caen. Los números detallados varían en cada ciclo; la imagen actualizada está en /benchmarks/speed.
Dos implicaciones prácticas. Primera: la ventana larga es genuinamente utilizable para cosas como la diligencia debida entre documentos, la revisión de código de repositorios completos y el estado conversacional de hilos largos, no solo un número en la hoja de especificaciones para poner en una presentación. Segunda: conviene seguir pensando en el caché de prompts para consultas repetidas contra el mismo corpus grande. Recargar 800k tokens de contexto en cada llamada es costoso en tiempo de reloj aunque la llamada a la API misma se complete sin problemas.
Cómo se compara con Opus 4.7 en contexto largo
Tanto Sonnet 4.6 como Opus 4.7 ofrecen ventanas de un millón de tokens. La diferencia es la que se espera:
- Opus 4.7 es más cuidadoso, más cauteloso y razona a través de cadenas más largas de pasos internos antes de responder.
- Sonnet 4.6 es más rápido con la misma entrada y produce respuestas más cercanas a la primera interpretación creíble en lugar de trabajar a través de alternativas.
- Para recuperación pura —"encuentra este dato en este documento de 800k tokens"— los dos están cerca. Para síntesis a través de muchos datos dispersos, Opus generalmente gana.
- Para cargas de trabajo de contexto largo sensibles al coste donde no se necesita específicamente razonamiento de la cima de la pila, Sonnet 4.6 es la elección correcta.
Pruébelos con sus propios prompts. Las diferencias en cargas de trabajo reales rara vez coinciden con las brechas en benchmarks públicos.
Visión que justifica su uso
Sonnet 4.6 mantiene el stack de visión de la línea 4.x. Capturas de pantalla de documentos, PDFs escaneados renderizados como imágenes de página, capturas de paneles de control, diagramas. La extracción de tablas es limpia. Los gráficos con tamaños de etiqueta razonables se describen con precisión.
Los mismos puntos débiles que en el resto de la familia Claude. La escritura manuscrita es variable. Las figuras científicas densas con etiquetas de ejes pequeñas se leen parcialmente de forma incorrecta. Todo aquello en que un humano necesitaría hacer zoom para leer la fuente se beneficia de un paso de verificación.
Para cargas de trabajo que combinan entrada de visión con la ventana de contexto larga —por ejemplo, un PDF completo renderizado como imágenes de página junto con metadatos estructurados— Sonnet 4.6 es una de las opciones más capaces del mercado. Gemini 3 Pro Preview compite aquí en condiciones prácticamente iguales.
Su posición frente al campo
El panorama competitivo honesto de Sonnet 4.6:
Frente a Opus 4.7: Sonnet 4.6 es más rápido y más barato de operar; Opus 4.7 razona con más cuidado en tareas complejas. Para cargas de trabajo donde el trabajo del modelo es extraer datos de una entrada larga y resumirlos, Sonnet suele ser suficiente. Para cargas de trabajo que implican razonamiento de múltiples pasos sobre una entrada larga, Opus es la mejor opción.
Frente a Gemini 2.5 Pro y GPT-5 de tier medio: Sonnet 4.6 gana en consistencia de rechazos y prosa administrativa en lenguas europeas. Gemini gana en multimodalidad nativa más allá de imágenes. GPT-5 de tier medio gana en velocidad bruta para turnos conversacionales cortos.
El panorama por categorías está en /benchmarks/leaderboard y /benchmarks/intelligence.
Cuándo no es la herramienta adecuada
Cargas de trabajo donde 200k tokens son suficientes. Sonnet 4.5 es más barato de operar y se comporta de manera similar dentro de su ventana. La capacidad de un millón de tokens tiene un coste en latencia y complejidad operacional que no se debería pagar a menos que sea necesario.
Voz en tiempo real. Sin entrada de audio. La guía de pipeline de voz en /usecases/voice cubre la arquitectura correcta.
Clasificación barata de alto volumen. La computación de tier medio en modelos con capacidad de contexto largo es el gasto con la forma equivocada para enviar millones de prompts cortos. Claude Haiku 4.5 o una de las variantes más pequeñas de Gemini Flash hace este trabajo a un nivel de coste diferente.
Generación de código en frameworks de rápida evolución. Estilo de salida conservador. Para trabajo ajustado al IDE, la encuesta en /usecases/code cubre las alternativas.
Despliegue auto-alojado o fine-tuning. Anthropic no distribuye pesos. La encuesta de pesos abiertos en /usecases/local es el punto de partida correcto cuando esas restricciones aplican.
Notas de despliegue
API estándar de Anthropic. REST. Streaming. Los prompts de sistema se comportan de manera predecible. El uso de herramientas es suficientemente fiable para construir agentes de producción.
La residencia de datos en la UE sigue siendo el punto de fricción recurrente. La inferencia de Anthropic corre en AWS y Google Cloud, y la API pública no expone un parámetro de selección de región para ningún modelo Claude. De serie, no se garantiza una ruta de inferencia exclusivamente de la UE. Los contratos enterprise pueden negociar cláusulas de residencia. Para restricciones estrictas de residencia, las opciones de peso abierto analizadas en /usecases/local son el punto de partida correcto.
Los logs se conservan treinta días por defecto para monitoreo de abusos. Las entradas no se usan para entrenamiento salvo que se acepte explícitamente. La retención cero es una negociación contractual, no un interruptor de configuración.
Cuándo elegirlo
Use Claude Sonnet 4.6 cuando:
- La carga de trabajo supere regularmente los 200k tokens de entrada.
- Quiera la velocidad y la postura de rechazo del estilo Sonnet en lugar de la profundidad de razonamiento del tier Opus.
- Ejecute diligencia debida entre documentos, revisión de código de repositorios completos u otras tareas donde la ventana larga justifique su uso.
- La prosa administrativa o legal en lenguas europeas forme parte de la entrada.
Elija otra opción cuando:
- La carga de trabajo encaje cómodamente dentro de los 200k tokens. Use Sonnet 4.5.
- Necesite razonamiento de la cima de la pila en la entrada larga. Suba a Opus 4.7.
- Necesite un coste por llamada inferior a un centavo en prompts cortos. Baje a Haiku.
- El audio, la voz o el vídeo formen parte de la carga de trabajo.
El resumen: Sonnet 4.6 es la respuesta correcta para cargas de trabajo de tier medio con contexto largo. No es la respuesta correcta para todo, y eso está bien. Para su franja específica, se encuentra entre los modelos más sólidos del mercado.
Pruébelo con su propio prompt de contexto largo en /live-test. La diferencia entre modelos es más clara cuando la entrada es lo suficientemente grande como para ponerlos a prueba.
Última revisión técnica: 2026-05-22 — Tokonomix.ai
