Claude Sonnet 4 ahora admite un contexto de 1 millón de tokens

 (anthropic.com)
2 puntos por GN⁺ 2025-08-13 | 1 comentarios | Compartir por WhatsApp
  • Claude Sonnet 4 de Anthropic ahora ofrece un contexto de hasta 1 millón de tokens, lo que permite procesar grandes bases de código o múltiples documentos de una sola vez
  • Con la mejora en el soporte de contexto, ahora son posibles diversos casos de uso, como análisis de código a gran escala, procesamiento de grandes colecciones de documentos y desarrollo de agentes que mantienen el contexto
  • En el caso de prompts que superen los 200,000 tokens, aumenta la tarifa de la API; es posible reducir costos mediante prompt caching y procesamiento por lotes
  • Clientes reales como Bolt.new e iGent AI mejoraron significativamente su productividad y sus capacidades de IA con esta función
  • Actualmente, el soporte de contexto largo de Sonnet 4 está disponible en beta en Anthropic API y Amazon Bedrock, y pronto también llegará a Google Cloud

Soporte para contexto de 1 millón de tokens

  • Claude Sonnet 4, a través de la Anthropic API, ahora admite hasta 1 millón de tokens de contexto
  • Esto permite procesar en una sola solicitud más de 75,000 líneas completas de código o múltiples artículos de investigación de forma integrada
  • La función beta de contexto de 1 millón de tokens ya está disponible en Anthropic API y Amazon Bedrock, y Vertex AI de Google Cloud también la admitirá pronto

Un contexto más largo, casos de uso más amplios

  • Análisis de código a gran escala: ahora es posible cargar una base de código completa (incluyendo archivos fuente, pruebas y documentación) de una sola vez para entender la estructura del proyecto, identificar relaciones entre archivos y proponer mejoras de código basadas en el diseño del sistema
  • Resumen integrado de documentos: permite analizar en lote cientos de contratos legales, artículos académicos y especificaciones técnicas, y obtener insights integrales manteniendo las relaciones entre los documentos
  • Agentes que mantienen el contexto: incluso a lo largo de cientos de llamadas a herramientas y flujos de trabajo de múltiples pasos, es posible desarrollar agentes conversacionales que mantengan un estado consistente incluyendo la documentación completa de la API, definiciones de herramientas y el historial de interacciones

Política de precios de la API

  • Prompts de hasta 200,000 tokens: entrada $3/1 millón de tokens, salida $15/1 millón de tokens
  • Prompts de más de 200,000 tokens: entrada $6/1 millón de tokens, salida $22.5/1 millón de tokens
  • Al aplicar prompt caching, se puede reducir la latencia y el costo
  • Al combinar el contexto de 1 millón de tokens con procesamiento por lotes, se puede lograr una reducción adicional de hasta 50% en costos

Casos de uso de clientes

  • Bolt.new

    • Bolt.new está impulsando la innovación en el desarrollo web al integrar Claude en una plataforma de desarrollo basada en la web
    • "Gracias a la ventana de contexto de 1 millón de Sonnet 4, los desarrolladores ahora pueden trabajar con proyectos más grandes con mayor precisión"

  • iGent AI

    • iGent AI, con sede en Londres, Reino Unido, convierte conversaciones en código ejecutable mediante un socio de IA llamado Maestro
    • "Las capacidades de ingeniería de software autónoma, que antes eran imposibles, ahora se hacen realidad con el contexto de 1 millón de tokens de Sonnet 4, permitiendo operar sesiones de varios días sobre bases de código reales"

Cómo usarlo y planes a futuro

  • La función de contexto largo está disponible en beta para clientes de Tier 4 y planes personalizados de la Anthropic API, y se expandirá a más usuarios en las próximas semanas
  • También está disponible en Amazon Bedrock, y el soporte para Google Cloud Vertex AI llegará pronto
  • Hay planes para incorporar contexto largo a otros productos de Claude
  • Se puede consultar información detallada en la documentación oficial y la página de precios

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-13
Opiniones de Hacker News

  • Se siente como una necesidad urgente que los LLM realmente mantengan muy bien el contexto en tareas profesionales de ingeniería de software; los anuncios de que un modelo nuevo mejoró un poco no resultan muy interesantes en la práctica real. Pero el precio es el factor más decisivo. Está bien que me permita meter suficiente de mi codebase dentro de la ventana de contexto, pero como el precio subió bastante, por ahora creo que lo correcto es gestionar mejor el contexto. Que yo use mucho la ventana de contexto beneficia al proveedor del servicio, pero siento que hace falta evaluar por separado qué tan bien Sonnet realmente mantiene el enfoque, así que es difícil estar seguro de su valor real.

    • El contexto está en el repo, y hay que aceptar que el LLM no siempre puede tener todo el contexto necesario, especialmente porque los repos grandes ni siquiera caben completos en una sola máquina. Para completar una tarea específica, hay que quitar la información innecesaria para mantener el foco; si metes todo, en realidad pierde concentración. Antes la ventana era demasiado pequeña, y todavía creo que sigue siéndolo, pero al final lo importante es tener la capacidad de entender el repo haciendo las preguntas correctas.

    • Si metes demasiado contexto, aumenta el riesgo de que el LLM se confunda solo. Cuando avanza con contextos largos sin resetearse, empieza a perder foco.

    • Creo que hace falta entrenar a la IA para que trabaje solo con información abstraída, no con toda la codebase. Los humanos tampoco trabajamos con todo el código en la cabeza, así que los LLM tampoco deberían necesitar hacerlo.

    • Después de trabajar varias semanas con Claude Code, llegué a la conclusión de que el valor práctico de la IA agéntica es más bien negativo. Aun así, pienso volver a probar en 6-8 meses.

    • Creo que el objetivo no es simplemente meter más código de una sola vez en el contexto. Algunas tareas sí tienen un mínimo de contexto necesario, pero un modelo de 1M de contexto exige nuevas formas de cargarle los datos. La verdadera fortaleza de este modelo está en problemas de análisis profundo como exploración iterativa de largo horizonte, aprendizaje en contexto y reconstrucción; por ejemplo, hay trabajos de amplitud como aplicar un cambio de API en 100 archivos, pero también trabajos de profundidad donde pruebas 15 enfoques hasta encontrar la solución, y Sonnet 1M muestra una capacidad única especialmente en esto último.

  • Se proponen algunos tips para quienes usan Claude Code y se preocupan por el consumo de tokens.

    1. Juntar el contexto necesario para la tarea y cargar bastante de la codebase.
    2. En cada punto lógico de pausa, presionar doble escape para volver a un checkpoint cargado de contexto (sin volver a gastar esos tokens).
    3. Decirle a Claude que “el desarrollador completó la tarea X” y meter eso en el contexto para recibir feedback (suele señalar más problemas en código escrito por “otro” que en el escrito por uno mismo). Para usar varios chats en paralelo, se puede llamar al mismo hilo con /resume y hacer doble escape hasta un punto con mucho contexto para resetear.

    • También usa el método de decirle a Claude: “en otra sesión escribiste la tarea X”, y aprovechar ese contexto para hacer preguntas o pedir cambios.

    • Yo también lo hago seguido, pero no siempre funciona bien. A veces ayuda más usar Claude con todo el contexto completo de la conversación.

    • La latencia baja muchísimo. No hace falta esperar a que un Claude nuevo vuelva a cargar todo el contexto desde cero.

    • Todo este proceso se siente como astrología para programadores (astrogy): si no se lo dices, no hay forma de saber qué va a pasar mientras el agente trabaja en la codebase.

    • Es curioso preguntarse por qué Claude encuentra más problemas cuando le dices que el código lo escribió otro desarrollador.

  • Hasta ahora, el uso más útil que he encontrado para Claude Code es preguntarle directamente: “¿hay algún bug en el diff actual?”. Entonces el chatbot analiza los cambios con mucho cuidado y detecta rápido bugs sutiles que normalmente requerirían mucho tiempo y múltiples despliegues para salir a la luz, además de enumerar con detalle varios puntos para mejorar la corrección del código.

    • Sorprende que funcione justo como uno quiere sin necesidad de pedirle explícitamente que “piense más profundamente”.

    • Por mi experiencia usándolo en tareas no relacionadas con programación, le falta creatividad, pero como lector crítico y minucioso es excelente.

    • También hay quien propone implementar esta función de forma concreta como un hook de Claude Code.

    • Yo mismo voy a probar este método desde mañana.

  • Mi experiencia actual con estas herramientas es la siguiente:

    1. Ayudan mucho al comenzar un lenguaje, framework, utilidad o proyecto greenfield nuevo. Luego toca revisar el código parseado y preguntarse si de verdad se puede confiar en él, pero como igual da flojera interpretarlo uno mismo, a veces terminas creyéndole porque “funciona”.
    2. En lenguajes o frameworks que ya conoces bien, más bien te hacen perder productividad. El tiempo para redactar el contexto adecuado para el prompt es parecido o mayor al de escribirlo tú mismo. En algunos casos funciona, pero es fácil que produzca código ambiguo con pinta de junior. Alguien sin experiencia puede no detectar el problema de inmediato. Lo he probado con Typescript, Kotlin, Java y C++ en varios entornos como sitios web, componentes de ESPHome, backend APIs y scripts de Node. Mi conclusión es que sirve para hobbies, scripts y prototipos, pero todavía le falta para código enterprise.

    • Me pasó algo parecido (Cline + Sonnet & Gemini durante 1 año), hasta que conocí Claude Code y, sobre todo, aprendí a “gestionar el contexto de verdad y de forma limpia”, y ahí sentí un avance real. La clave es tratar a la IA no como generador de código, sino como arquitecto e implementador. Últimamente siempre le hago escribir primero a CC el documento de diseño de lo que queremos hacer, y le indico que consulte tanto el código como la documentación. Yo lo reviso para confirmar claramente la dirección deseada, luego divido el trabajo en chunks y también subdivido cada chunk. Una vez definida la estructura inicial, limpio el contexto, le hago leer el documento por etapas y luego implementar. Si hace falta, corrijo la dirección o edito el documento y reinicio solo esa etapa. En cada etapa: commit, limpiar contexto, siguiente etapa. De esta forma, funciones que antes me tomaban 2-3 días ahora las saco en menos de un día. Al final obtengo entregables bien cuidados: documentación validada, unit tests, Storybook, accesibilidad (arai, etc.). Y al final paso code review con otro modelo. Aunque todavía no me da una velocidad aplastante, lo veo como una inversión a futuro en habilidades para herramientas que siguen mejorando.

    • Para mí esta herramienta se parece a la sensación del scaffolding de rails new en la época de Ruby on Rails. Los LLM son ideales para crear el esqueleto inicial de un proyecto, es decir, áreas donde basta con entender bien la documentación oficial de la herramienta. En cambio, son menos útiles en sistemas legacy o proyectos con muchos requerimientos externos. En herramientas que cambian rápido, como Databricks, casi no sirven. Si el nombre, la sintaxis o las funciones cambiaron después de los datos de entrenamiento, solo queda alguna posibilidad si metes agresivamente la documentación en tiempo real dentro del prompt.

    • Mi workflow usa Claude Desktop junto con el filesystem del servidor mcp. Le digo a Claude las rutas de los archivos relacionados y le pido resolver la tarea. Claude lee y analiza directamente los archivos y hace las modificaciones o adiciones necesarias. Normalmente yo solo le pego algunos build errors y él los corrige otra vez. También me impresiona que escriba código nuevo manteniendo el mismo estilo del código existente. Lo he usado en Typescript y C#, y en mi experiencia el resultado no se queda en nivel hobby.

    • Yo no soy programador, pero necesito código en Python y bash para mi trabajo. También llevo algunos proyectos personales y sitios web. Gracias a Claude Code pude implementar pequeños proyectos que antes no podía hacer por falta de habilidad o tiempo. Ahora incluso puedo mejorar mi entorno de emacs por mi cuenta; también me genera funciones de lisp sin problema. Para mí es una herramienta perfecta: me destraba cosas que antes me bloqueaban y me hace la vida más fácil.

    • Lo he usado con Typescript, Go, SQL y Rust. Rust fue demasiado complejo y salieron muchos errores; solo quiero terminar rápido ese proyecto (aunque el proyecto en sí ya es muy difícil). Go, en cambio, es tan simple que resulta sumamente productivo: velocidad al doble. Typescript va bien para componentes y animaciones en React. SQL/PostgreSQL igual. Odio el boilerplate de los stored procedures, y el LLM me lo reduce, así que hasta me ahorra dolor de muñeca.

  • Sin duda está bien que haya cada vez más opciones, pero al mismo tiempo, si metes demasiado contexto, la calidad de salida del LLM puede bajar, porque se vuelve más fácil que se distraiga. Si los usuarios no entienden ese trade-off y solo dependen del modo automático, me preocupa la calidad del código generado con Claude Code.

    • Se comparten algunos enlaces que vale la pena revisar

    • Hasta ahora el contexto largo no está integrado en Claude Code. Dicen que “están evaluando cómo aplicar contexto largo a otros productos”, así que supongo que ya reconocieron este problema y están pensando cómo resolverlo. Parece que quieren ofrecer una solución antes de que los usuarios empiecen a generar costos extra en planes caros.

    • Alguien pregunta qué alternativa recomendarían. Se está acostumbrando a Claude Code, pero todavía no domina las mejores prácticas.

    • El equipo de Chroma está investigando este problema y pronto publicará datos numéricos.

  • Alguien pregunta si Opus no será mejor, y comenta que nota una gran diferencia cuando se le acaban los tokens y lo cambian a Sonnet por la fuerza. Dice que ya acumuló experiencia y le sobran ideas, pero que programar le costaba mucho; desde que apareció Claude, ahora vuela tanto para implementar ideas como para testing y corrección de bugs.

    • Pero también le preocupa que, si sigue dependiendo solo de Claude Code, sus habilidades reales de desarrollo terminen deteriorándose.

  • El gran problema de las chat apps (ChatGPT, Claude.ai) son los comportamientos raros relacionados con la ventana de contexto (recortes repentinos, resúmenes, reinserción de “snippets fantasma”, etc.). Sería más cómodo que el usuario pudiera elegir directamente si quiere mantener el contexto o empezar un chat nuevo, pero en la práctica no queda otra por las limitaciones de cómputo y de los planes. De hecho, para poder enviar todo el contexto completo hay que usar herramientas para desarrolladores (como Google AI Studio) o chat apps envueltas sobre la API. Si haces una chat app custom, incluso podrías insertar timestamps en cada mensaje e indicarle al LLM: “cada 10 minutos, resume lo ocurrido en una nueva fila de una tabla Markdown”.

    • También se sugiere que, en lugar de usar intervalos de tiempo, quizá sea mejor hacerlo “por mensaje”, por ejemplo: “cada décimo mensaje, resume en blah-blah.md”.

  • Creo que este plan de precios es el primer caso en que se reconoce que el costo sube casi “cuadráticamente” conforme aumentan los tokens. Parece ser la primera vez que un proveedor de LLM refleja una estructura de precios no lineal. Este enfoque se parece a las leyes de escalado de inferencia que ya conocemos.

  • También se señala una discusión relacionada

  • La función está genial, pero me pregunto qué se podría hacer para mejorar la velocidad de inferencia. Personalmente, con 200K de contexto me basta, pero me gustaría que respondiera más rápido. Creo que mucha gente estaría satisfecha incluso con menos contexto, si el agente trabajara mucho más rápido (ahora mismo son 2-3 minutos de espera por prompt).