Claude Sonnet 4 agora oferece suporte a contexto de 1 milhão de tokens

 (anthropic.com)
2 pontos por GN⁺ 2025-08-13 | 1 comentários | Compartilhar no WhatsApp
  • O Claude Sonnet 4 da Anthropic agora oferece contexto de até 1 milhão de tokens, permitindo processar grandes bases de código ou vários documentos de uma só vez
  • Com o suporte de contexto ampliado, passam a ser possíveis vários usos, como análise de código em larga escala, processamento de grandes conjuntos de documentos e desenvolvimento de agentes que mantêm o contexto
  • No caso de prompts que ultrapassam 200 mil tokens, há aumento no preço da API, e é possível reduzir custos com cache de prompt e processamento em lote
  • Clientes reais como Bolt.new e iGent AI aumentaram significativamente a produtividade e os recursos de IA com essa funcionalidade
  • No momento, o suporte a contexto longo do Sonnet 4 está disponível em beta na Anthropic API e Amazon Bedrock, com lançamento em breve também no Google Cloud

Suporte a contexto de 1 milhão de tokens

  • O Claude Sonnet 4 via Anthropic API agora oferece suporte a até 1 milhão de tokens de contexto
  • Com isso, passa a ser possível processar de forma integrada, em uma única solicitação, mais de 75.000 linhas de código ou vários artigos de pesquisa
  • O recurso beta de contexto de 1 milhão de tokens já está disponível na Anthropic API e no Amazon Bedrock, e o Vertex AI do Google Cloud também deve receber suporte em breve

Contexto mais longo, casos de uso ampliados

  • Análise de código em larga escala: é possível carregar de uma vez toda a base de código (incluindo arquivos-fonte, testes e documentação), entender a estrutura do projeto, identificar relações entre arquivos e propor melhorias de código com base no design do sistema
  • Resumo integrado de documentos: é possível analisar em lote centenas de contratos jurídicos, artigos acadêmicos e especificações técnicas, extraindo insights abrangentes enquanto se preservam as relações entre os documentos
  • Agentes com manutenção de contexto: mesmo em processos com centenas de chamadas de ferramentas e fluxos de trabalho em múltiplas etapas, é possível desenvolver agentes conversacionais que mantêm um estado consistente ao incluir toda a documentação da API, definições de ferramentas e histórico de interações

Política de preços da API

  • Prompts com até 200 mil tokens: entrada de US$ 3 por milhão de tokens, saída de US$ 15 por milhão de tokens
  • Prompts com mais de 200 mil tokens: entrada de US$ 6 por milhão de tokens, saída de US$ 22,5 por milhão de tokens
  • Ao aplicar cache de prompt, é possível reduzir a latência e os custos
  • Ao combinar o contexto de 1 milhão de tokens com processamento em lote, é possível obter até 50% de economia adicional

Casos de uso de clientes

  • Bolt.new

    • A Bolt.new está inovando no desenvolvimento web ao integrar o Claude à sua plataforma de desenvolvimento baseada na web
    • "Com a janela de contexto de 1 milhão do Sonnet 4, os desenvolvedores agora conseguem lidar com projetos maiores com alta precisão"

  • iGent AI

    • A iGent AI, sediada em Londres, no Reino Unido, converte conversas em código executável por meio do parceiro de IA chamado Maestro
    • "Recursos de engenharia de software autônoma que antes eram impossíveis agora se tornam viáveis com o contexto de 1 milhão de tokens do Sonnet 4, permitindo operar sessões por vários dias sobre bases de código reais"

Como usar e próximos passos

  • O recurso de contexto longo está disponível em beta para clientes Tier 4 e de planos personalizados da Anthropic API, com expansão para um grupo maior de usuários nas próximas semanas
  • O suporte também já está disponível no Amazon Bedrock, e o suporte no Google Cloud Vertex AI deve chegar em breve
  • Há planos para introduzir contexto longo em outros produtos da família Claude
  • Mais informações podem ser consultadas na documentação oficial e na página de preços

Leituras relacionadas

1 comentários

 
GN⁺ 2025-08-13
Comentários do Hacker News

  • Sinto que, em trabalho profissional de engenharia de software, é realmente essencial que um LLM tenha uma capacidade excelente de manter contexto; anúncios de que um novo modelo melhorou um pouco nisso não são tão interessantes na prática. Mas o preço é o principal fator decisivo. É bom poder colocar uma parte suficientemente grande da minha base de código na janela de contexto, mas como o preço subiu bastante, acho que no momento faz mais sentido gerenciar melhor o contexto. Usar muito a janela de contexto é vantajoso para o provedor do serviço, mas ainda acho que seria preciso avaliar separadamente o quão bem o Sonnet realmente mantém o foco, então é difícil ter certeza do valor real.

    • O contexto está no repositório, e precisamos aceitar que o LLM nunca vai ter sempre todo o contexto necessário, especialmente porque repositórios grandes nem cabem em uma máquina só. Para concluir uma tarefa específica, é preciso remover informações desnecessárias para manter o foco; se colocar tudo, a concentração piora. No passado a janela era pequena demais, e ainda acho que continua sendo, mas no fim das contas o que importa é a capacidade de entender o repositório fazendo as perguntas certas.

    • Se você colocar contexto demais, aumenta o risco de o LLM se confundir sozinho. Em contextos longos, seguir em frente sem reset acaba dispersando o foco.

    • Acho que é preciso treinar a IA para lidar apenas com informações abstraídas, e não com a base de código inteira. Nem humanos trabalham com todo o código na cabeça ao mesmo tempo, então o LLM também não precisa fazer isso.

    • Depois de trabalhar algumas semanas com Claude Code recentemente, cheguei à conclusão de que o valor prático de uma IA do tipo agente é, na verdade, negativo. Mesmo assim, pretendo tentar de novo daqui a 6–8 meses.

    • Acho que o objetivo de uso não é simplesmente colocar mais código de uma vez no contexto. Algumas tarefas realmente exigem um mínimo de contexto necessário, mas um modelo com 1M de contexto pede novas formas de alimentar os dados. A verdadeira força desse modelo está em problemas de análise profunda, como exploração iterativa de longo horizonte, in-context learning e reconstrução. Por exemplo, há tarefas de largura, como aplicar uma mudança de API em 100 arquivos, mas ele também tem força em tarefas de profundidade, como testar 15 abordagens diferentes até encontrar a solução. O Sonnet 1M parece especialmente excepcional nesse segundo tipo.

  • Sugere algumas dicas para usuários preocupados com Claude Code e uso de tokens

    1. Juntar o contexto necessário para a tarefa e colocar bastante da base de código
    2. Em cada ponto lógico de parada, apertar escape duas vezes para voltar a um checkpoint cheio de contexto (sem gastar novamente aqueles tokens)
    3. Dizer ao Claude que “o desenvolvedor concluiu a tarefa X” e colocar isso no contexto para receber feedback (ele aponta mais problemas em código escrito por outra pessoa do que no código do próprio usuário) Para usar vários chats em paralelo, dá para chamar a mesma thread com /resume e resetar para um ponto rico em contexto usando duplo escape.

    • Eu uso um método em que digo ao Claude: “em outra sessão você escreveu a tarefa X”, e então aproveito esse contexto para fazer perguntas ou pedir mudanças.

    • Eu também faço isso com frequência, mas nem sempre funciona bem. Às vezes ajuda mais usar o Claude mantendo o contexto da conversa inteira.

    • A latência cai bastante. Não é preciso esperar um novo Claude recarregar o contexto do zero.

    • Esse processo parece astrologia para programadores (astrogy). Se você não disser explicitamente, não dá para saber o que vai acontecer enquanto o agente trabalha na base de código.

    • O curioso é que fico me perguntando por que o Claude encontra mais problemas quando o código é apresentado como se tivesse sido escrito por outro desenvolvedor.

  • Até agora, o uso mais útil que tive com Claude Code foi perguntar diretamente: "há bugs no diff atual?". Aí o chatbot analisa cuidadosamente as mudanças, encontra rapidamente bugs sutis que normalmente exigiriam muito tempo e várias implantações para aparecer, e aponta detalhadamente vários pontos para aumentar a correção do código.

    • É curioso que ele funciona exatamente como eu quero mesmo sem eu pedir explicitamente para “pensar mais profundamente”.

    • Pela minha experiência usando também em tarefas que não são de programação, ele tem pouca criatividade, mas é excelente como leitor crítico e minucioso.

    • Também houve a sugestão de implementar isso de forma concreta como um hook do Claude Code.

    • Eu mesmo vou testar esse método já a partir de amanhã.

  • Minha experiência atual com essas ferramentas é a seguinte

    1. Elas ajudam muito ao começar uma nova linguagem, framework, utilitário ou projeto greenfield. Depois eu fico lendo o código e pensando se dá mesmo para confiar, mas como também tenho preguiça de interpretar tudo sozinho, às vezes acabo confiando porque “está funcionando”.
    2. Em linguagens ou frameworks que eu já conheço bem, a produtividade piora. O tempo gasto escrevendo um contexto adequado para o prompt é igual ou maior que o de escrever direto. Em algumas situações funciona, mas o resultado tende a virar um código meio duvidoso, com cara de coisa feita por júnior. Alguém sem experiência pode nem perceber o problema na hora. Já usei em websites, componentes do ESPHome, APIs de backend, scripts de node e outros ambientes com Typescript, Kotlin, Java e C++. Minha conclusão é que é bom para hobby, scripts e protótipos, mas ainda não chega ao nível de código enterprise.

    • Comigo foi parecido (Cline + Sonnet & Gemini por 1 ano), até eu conhecer Claude Code e, acima de tudo, aprender a “gerenciar contexto de forma realmente limpa”; aí senti uma virada de verdade. O segredo é tratar a IA não como geradora de código, mas como arquiteta e implementadora. Recentemente, eu sempre faço o CC escrever primeiro um documento de design para a tarefa que vamos realizar, e mando ele consultar tanto o código quanto a documentação. Eu reviso isso e confirmo claramente a direção desejada, depois divido o trabalho em chunks, e subdivido cada chunk também. Quando a definição inicial termina, limpo o contexto; então, em cada etapa, mando ele ler o documento e implementar. Se necessário, ajusto a direção da mudança ou corrijo o documento e reinicio só aquela etapa. Faço commit em cada etapa, limpo o contexto e vou para a próxima. Assim, funcionalidades que antes levavam 2–3 dias agora consigo fazer em menos de um dia. No fim, saem entregas bem cuidadas, com documentação validada, testes unitários, Storybook, acessibilidade (arai etc.). No final ainda faço code review com outro modelo. Mesmo que agora eu ainda não esteja num nível de velocidade absurdo, vejo isso como um investimento no futuro das minhas habilidades diante de ferramentas que continuam evoluindo.

    • Para mim, essa ferramenta lembra o scaffolding do antigo Ruby on Rails com rails new. LLM é ideal para a área em que basta conhecer bem a documentação oficial da ferramenta, ou seja, para montar o esqueleto inicial de um projeto. Já em sistemas legados ou projetos com muitas exigências externas, é menos útil. Para ferramentas que mudam rápido, como Databricks, quase não serve. Se o nome, a sintaxe ou as funções mudaram depois dos dados de treinamento, só usando agressivamente a documentação em tempo real no prompt ainda resta alguma chance.

    • Meu fluxo usa o Claude desktop junto com o filesystem do servidor mcp. Eu informo ao Claude os caminhos dos arquivos relevantes e mando resolver a tarefa. O Claude lê e analisa os arquivos por conta própria e faz as modificações ou adições necessárias. Normalmente, se eu só colar alguns erros de build, ele corrige de novo. Também me impressiona como ele escreve código novo mantendo o estilo já existente. Já usei com Typescript e C#. Pela minha experiência, o resultado não fica restrito a nível hobby.

    • Eu não sou programador, mas trabalho com coisas que exigem código em Python e bash. Também mantenho alguns projetos pessoais e sites. Graças ao Claude Code, consegui implementar pequenos projetos que antes eu não fazia por falta de habilidade e tempo. Agora até consigo melhorar meu próprio ambiente em emacs. Ele também cria funções em lisp com facilidade. Para mim, essa é a ferramenta perfeita. Resolve sem esforço coisas em que eu ficava travado e deixa minha vida mais fácil.

    • Já usei com Typescript, Go, SQL e Rust. Rust era complexo demais e veio cheio de erros; quero terminar esse projeto logo (embora o projeto em si já seja muito difícil). Go é tão simples como linguagem que a produtividade fica excelente, praticamente o dobro. Typescript funciona bem para componentes e animações em React. SQL/PostgreSQL também vai bem. Eu odeio boilerplate de procedures salvas, e o LLM reduz isso, então minhas mãos doem menos.

  • É definitivamente bom ter mais opções assim, mas ao mesmo tempo, se você colocar contexto demais, a qualidade da saída do LLM pode cair, porque ele tende a ficar mais disperso. Se o usuário não entende esse trade-off e depende apenas do modo automático, fico preocupado com a qualidade do código produzido com Claude Code.

    • Compartilha alguns links que valem a leitura

    • Até agora, contexto longo ainda não foi integrado ao Claude Code. Disseram que “estão estudando formas de aplicar contexto longo em outros produtos”. Imagino que eles já reconheçam o problema e estejam pensando em soluções. Parece que querem apresentar algo antes que usuários em planos caros passem a gerar custos extras.

    • Pergunta o que seria recomendável como alternativa. Está se acostumando com Claude Code, mas ainda não domina as melhores práticas.

    • A equipe da Chroma está estudando esse problema, e devem sair dados numéricos em breve.

  • Pergunta se o Opus não seria melhor, e diz que sente uma diferença grande quando os tokens acabam e ocorre a troca forçada para Sonnet. Também comenta que, embora tenha acumulado experiência e esteja cheio de ideias, programar sempre foi difícil; desde que Claude apareceu, consegue voar na implementação, testes e correção de bugs.

    • Mas também existe a preocupação de que, se continuar dependendo demais do Claude Code, a própria habilidade real de desenvolvimento acabe se deteriorando.

  • O grande problema dos apps de chat (ChatGPT, Claude.ai) são os comportamentos estranhos ligados à janela de contexto, como cortes repentinos, resumos e reinserção de “snippets fantasmas”. Seria mais confortável se o usuário pudesse escolher diretamente entre manter o contexto atual ou iniciar um novo chat, mas na prática isso é limitado por plano e capacidade computacional. Na realidade, só usando ferramentas para desenvolvedores (como Google AI Studio) ou apps de chat feitos em cima da API é que dá para enviar o contexto inteiro de forma completa. Se você criar um app de chat customizado, também pode inserir timestamps em cada mensagem e instruir o LLM a “a cada 10 minutos resumir o conteúdo daquele período em uma nova linha de uma tabela Markdown”.

    • Em vez de agrupar por tempo, alguém sugere que seria melhor fazer “por mensagem”, por exemplo: “a cada 10ª mensagem, resumir em blah-blah.md”.

  • Acho que este é o primeiro caso em que um plano de preços admite claramente que o custo sobe quase “ao quadrado” conforme a quantidade de tokens aumenta. Parece ser a primeira vez que um fornecedor de LLM reflete uma estrutura de cobrança não linear. Esse modelo lembra as leis de scaling de inferência que já conhecemos.

  • Também aponta uma discussão relacionada sobre o tema

  • O recurso é incrível, mas fico curioso sobre o que poderia ser feito para melhorar a velocidade de inferência. Pessoalmente, 200K de contexto já basta para mim; eu só queria respostas mais rápidas. Acho que muita gente ficaria satisfeita mesmo com um contexto menor, desde que o agente trabalhasse bem mais rápido (hoje são 2–3 minutos de espera por prompt).