Claude Sonnet 4.6 Testado: Quase-Opus pela Metade do Preço

Eu quase não testei o Sonnet 4.6.

Sério. Eu estava imerso em um fluxo de trabalho com o Opus 4.6 — agentes rodando, código sendo entregue, toda a máquina funcionando — e minha primeira reação quando a Anthropic lançou o Sonnet 4.6 foi "legal, vou ver isso na semana que vem." Aí um amigo no meu Discord me mandou um print de uma landing page de SaaS que o Sonnet 4.6 tinha gerado em um único prompt. Tipografia limpa. Sistema de cores coeso. Uma seção hero que parecia ter sido trabalhada por um designer durante três horas.

Parei o que estava fazendo e abri o console da API.

O que se seguiu foi uma maratona de 72 horas de testes que mudou fundamentalmente a forma como penso sobre a escolha de modelos para meus projetos. Porque a questão é a seguinte — sou um fiel do Opus desde o primeiro dia. O Opus 4.6 é meu cavalo de batalha. Meu modelo do dia a dia. O modelo em que confio para código em produção e arquiteturas complexas de agentes. Então, quando digo que o Sonnet 4.6 me fez questionar essa lealdade, entenda o peso do que estou dizendo.

Este não é um modelo que é "bem razoável pelo preço." Este é um modelo que iguala ou supera o Opus em tarefas específicas, rodando duas vezes mais rápido e custando aproximadamente a metade. E a janela de contexto de um milhão de tokens atualmente em beta? Isso muda o jogo para qualquer pessoa construindo sistemas de agentes ou trabalhando com grandes bases de código.

Submeti o Sonnet 4.6 a todos os testes que consegui imaginar — geração de front-end, simulações 3D, automação de navegador, desenvolvimento de jogos, gráficos SVG e builds completos de projetos dirigidos por agentes. Alguns resultados genuinamente me chocaram. Outros revelaram limitações claras que você precisa conhecer antes de fazer a troca.

Vou te guiar por tudo isso.

Por Que Mais um Sonnet Importa (Mesmo Se Você Já Usa o Opus)

Preciso abordar algo que vejo constantemente em comunidades de desenvolvedores: fadiga de modelos. A cada poucas semanas, um novo modelo é lançado e todo mundo debate se é "o tal." Eu entendo o ceticismo. A maioria das atualizações é incremental. Um ponto ou dois em algum benchmark que ninguém liga na prática.

O Sonnet 4.6 é diferente, e consigo identificar exatamente o porquê.

O Sonnet 4.5 anterior era sólido. Bom o suficiente para tarefas simples, rápido o bastante para aplicações em tempo real, barato o suficiente para rodar em escala. Mas tinha um teto. Raciocínio complexo com múltiplas etapas o atrapalhava. Arquivos de código longos faziam com que ele perdesse contexto e alucinasse nomes de funções que não existiam. Fluxos de agentes com mais de 3-4 etapas às vezes saíam dos trilhos.

O Sonnet 4.6 não apenas eleva esse teto — ele o remove para a maioria dos casos de uso práticos. Os números dos benchmarks contam parte da história: 79,6 no teste SWE-Bench verificado, pontuações estado-da-arte em codificação agentica e resultados de análise financeira que competem com modelos que custam o dobro. Mas benchmarks são apenas marketing até você rodar o modelo você mesmo.

Então eu rodei. Com tudo. Nas exatas tarefas para as quais uso o Opus todos os dias.

E o contexto de preços importa aqui. O Opus 4.6 custa aproximadamente $6 por milhão de tokens de entrada e $12 por milhão de tokens de saída. O Sonnet 4.6 mantém os preços do Sonnet 4.5: $3 entrada, $6 saída. Isso não é uma economia marginal — é metade do custo para um modelo que, nos meus testes, entrega 85-95% da capacidade do Opus dependendo da tarefa.

Para desenvolvedores solo e equipes pequenas que queimam créditos de API? Essa conta muda tudo. Mas será que a qualidade realmente se sustenta sob pressão? Eu precisava descobrir, começando pela tarefa que mais me importa — entregar código front-end real.

Geração de Front-End: O Teste Que Mais Me Surpreendeu

Tenho um teste padrão de front-end que rodo em cada modelo novo. Mesmo prompt, toda vez: gere uma landing page premium de SaaS com seção hero, grid de funcionalidades, tabela de preços, depoimentos e rodapé. Especifico a paleta de cores, preferências tipográficas e a vibe geral. Depois comparo a saída bruta em HTML/CSS.

O Opus 4.6 tem consistentemente produzido os melhores resultados neste teste. Estrutura de componentes limpa. Espaçamento sofisticado. Uso de cores que realmente parece que um designer deu uma olhada. Então minhas expectativas para o Sonnet 4.6 eram modestas — imaginei que produziria algo funcional mas obviamente um nível abaixo.

Eu estava errado.

A landing page que o Sonnet 4.6 gerou tinha tipografia melhor do que o Opus normalmente me entrega. As combinações de fontes eram mais intencionais. Os gradientes de cores eram mais suaves. A seção hero tinha uma sugestão sutil de animação nos comentários que, quando implementada, ficou genuinamente premium.

Onde ficou aquém: o comportamento responsivo precisou de mais ajuste manual do que a saída do Opus, e o componente do rodapé ficou levemente genérico. Mas são correções de 5 minutos. A fundação — a parte que leva mais tempo para acertar — foi excepcional.

Rodei este teste mais três vezes com briefings de design diferentes. O Sonnet 4.6 venceu duas de três. A que perdeu foi um dashboard dark-mode com componentes complexos de visualização de dados, onde o raciocínio mais forte do Opus sobre hierarquia de componentes fez uma diferença visível.

Aqui vai minha conclusão para quem trabalha com front-end: se você está gerando landing pages, sites de marketing ou interfaces SaaS padrão, o Sonnet 4.6 não é apenas "bom o suficiente" — pode ser a sua melhor opção. A vantagem de velocidade por si só (aproximadamente 2x mais rápido que o Opus) significa que você pode iterar mais rapidamente, e a economia de custos se acumula rápido quando você faz múltiplas rodadas de geração e refinamento.

Mas código front-end é uma coisa. E quanto a algo realmente complexo — como simular um sistema operacional inteiro?

A Simulação de Mac OS Que Bugou Minha Mente

Este teste começou como brincadeira. Um desenvolvedor na minha comunidade me desafiou a fazer o Sonnet 4.6 gerar uma interface funcional de Mac OS no navegador. "Sem chance de ele lidar com a complexidade," disse ele. "São muitos componentes interagindo."

Desafio aceito.

Dei ao Sonnet 4.6 um prompt detalhado descrevendo um desktop estilo Mac OS com Finder, Safari, Notes, Mail, Photos, Terminal, Calculator e Settings — todos funcionais até certo grau. Eu esperava um mockup estático com talvez alguns elementos clicáveis.

O que recebi foi de uma qualidade genuinamente perturbadora.

A janela do Finder abria e fechava. Você podia criar pastas e navegar entre elas. O Safari tinha uma barra de endereço funcional com gerenciamento básico de abas. O Notes permitia criar e editar entradas de texto. A Calculator realmente funcionava — cada botão, cada operação, resultados corretos. O Settings incluía personalização de wallpaper (com opções reais de wallpaper), controles deslizantes de volume e brilho com animações suaves, e uma barra de busca estilo Spotlight que filtrava aplicativos.

Era um sistema operacional de verdade? Obviamente não. Mas como uma geração de prompt único de um protótipo de UI interativo? Nunca vi nada parecido de um modelo nessa faixa de preço.

O music player foi o detalhe que me pegou. Ele não apenas tocava (simulava) faixas, mas animava o ícone do dock enquanto a "música" estava ativa. Esse é o tipo de detalhe de design que exige entendimento de contexto, expectativas do usuário e padrões de feedback visual — não apenas renderizar componentes.

Rodei o mesmo prompt no Opus 4.6 para comparação. O Opus produziu um resultado mais tecnicamente sofisticado com melhor tratamento de erros e gerenciamento de estado mais limpo. Mas a versão do Sonnet parecia melhor e tinha mais polimento interativo. É quase como se o Sonnet priorizasse a experiência do usuário enquanto o Opus priorizasse a engenharia.

Pontos fortes diferentes. Ambos impressionantes. Mas apenas um custa $3 por milhão de tokens de entrada.

A verdadeira questão, porém — a que eu estava mais nervoso a respeito — era como o Sonnet 4.6 lida com fluxos de trabalho de agentes com múltiplas etapas. Porque é onde eu vivo profissionalmente, e é onde o Opus tem sido insubstituível. Até agora.

Desenvolvimento Dirigido por Agentes: Boxelcraft e o Teste Multi-Agente

Este é o teste que realmente importa para o meu trabalho. Eu construo sistemas de agentes de IA profissionalmente. Meus clientes me pagam para arquitetar fluxos de trabalho onde múltiplos agentes colaboram, escrevem código, testam e iteram — muitas vezes de forma autônoma. O Opus 4.6 tem sido a espinha dorsal desses sistemas porque lida com planejamento complexo, raciocínio de contexto longo e uso de ferramentas melhor do que qualquer outra coisa disponível.

Então montei o teste mais difícil que consegui imaginar: uma implantação multi-agente autônoma usando Kilo Code (que, aliás, oferece $25 em créditos gratuitos — ótima forma de testar isso você mesmo). A tarefa? Construir um clone de Minecraft baseado em navegador do zero.

Os agentes dividiram o trabalho: um cuidou da geração de terreno, outro gerenciou as mecânicas de jogo (colocação de blocos, destruição, inventário), um terceiro trabalhou na UI (barras de vida, medidores de comida, elementos de HUD), e um agente coordenador gerenciou a arquitetura geral.

O resultado foi um jogo jogável chamado Boxelcraft. Geração de terreno com cavernas. Sistemas de vida e comida funcionais. Colocação e destruição de blocos. Um sistema básico de inventário.

Era perfeito? Nem de longe. O desempenho estava lento. Parte da geração de cavernas produziu artefatos visuais. A física tinha casos extremos onde você atravessava blocos. Mas aqui está a métrica que importa: os agentes completaram toda a build de forma autônoma. Sem intervenção humana. Sem debugging manual no meio do processo. O planejamento, implementação, testes e iteração aconteceram todos dentro do enxame de agentes.

Rodei testes similares com o Opus 4.6, e aqui vai a comparação honesta:

Essa diferença de velocidade e custo não é trivial. Para desenvolvimento iterativo — onde você roda agentes, revisa a saída, ajusta prompts e roda novamente — o Sonnet 4.6 permite fazer o dobro de iterações com o mesmo orçamento. E na minha experiência, mais iterações quase sempre supera melhor qualidade em uma única tentativa.

Dica profissional: Comecei a usar uma abordagem híbrida. Sonnet 4.6 para as iterações iniciais de build (rápido, barato, te leva a 80%), depois Opus 4.6 para a passada final de polimento (minucioso, pega casos extremos, produz código mais limpo). Isso reduziu meus custos de fluxo de agentes em cerca de 40% sem queda perceptível de qualidade no resultado final.

Tem mais uma capacidade que testei e que merece sua própria seção — porque é a que tem as implicações mais práticas para desenvolvedores que querem automatizar trabalho real, não apenas gerar demos.

Automação de Navegador: Onde o Sonnet 4.6 Genuinamente Se Destaca

Tenho construído sistemas de automação de navegador para clientes desde 2023 — bots de pesquisa, scrapers de dados, agentes de preenchimento de formulários, dashboards de monitoramento. Este é um trabalho braçal que consome tempo de desenvolvedor, e é exatamente onde modelos de IA podem entregar ROI massivo.

Meu teste: dar ao Sonnet 4.6 a tarefa de criar uma configuração completa de automação de navegador usando Python com Playwright, automatizar uma busca no Google pelas últimas notícias de IA, extrair as cinco principais manchetes, salvá-las em um CSV e exibir os resultados em um dashboard em tempo real.

O modelo gerou todo o pipeline em uma única resposta. Script Python com Playwright para controle do navegador. Tratamento assíncrono adequado. Operações de escrita em CSV com timestamps. Um dashboard simples em Flask que lê o CSV e exibe os resultados com auto-refresh.

O que me impressionou não foi o fato de funcionar — o Opus também faz isso. O que me impressionou foi como o código estava limpo logo na primeira versão. O tratamento de erros era cuidadoso (lógica de retry para falhas de rede, degradação graciosa se a estrutura do alvo de scraping mudar). Os seletores do Playwright eram específicos o suficiente para serem robustos, mas não tão rígidos que uma mudança menor no DOM quebraria tudo.

Implantei esse pipeline e deixei rodando por 48 horas. Zero crashes. O CSV acumulou dados de forma confiável. O dashboard permaneceu responsivo.

Para comparação, quando dei a mesma tarefa ao Opus, ele produziu um código levemente mais sofisticado — melhor logging, mais parâmetros configuráveis, um design de dashboard mais polido. Mas a versão do Sonnet estava pronta para produção sem modificações, e foi gerada em aproximadamente metade do tempo.

# Abordagem do Sonnet 4.6 para o scraper — limpa e prática
async def scrape_ai_headlines(page):
    await page.goto("https://news.google.com/search?q=artificial+intelligence")
    await page.wait_for_selector("article h3", timeout=10000)

    headlines = await page.eval_on_selector_all(
        "article h3",
        "elements => elements.slice(0, 5).map(el => el.innerText)"
    )

    timestamp = datetime.now().isoformat()
    with open("headlines.csv", "a", newline="") as f:
        writer = csv.writer(f)
        for headline in headlines:
            writer.writerow([timestamp, headline])

    return headlines

Nada sofisticado. Nada super-engenheirado. Apenas código sólido e funcional que faz exatamente o que foi pedido. E sinceramente? É isso que eu quero de um modelo de IA 90% das vezes. Não preciso que ele arquitete um microsserviço distribuído. Preciso que ele escreva o script de automação que me poupa duas horas de trabalho manual — rápido, barato e correto.

Mas estaria sendo injusto com você se falasse apenas sobre onde o Sonnet brilha. Encontrei limitações reais também, e você precisa saber delas antes de tomar qualquer decisão.

Onde o Sonnet 4.6 Fica Aquém (A Avaliação Honesta)

Tenho sido positivo sobre este modelo, e ele merece os elogios. Mas existem áreas específicas onde ele claramente fica atrás do Opus 4.6, e fingir o contrário seria desonesto.

Geração de SVG e gráficos complexos. Rodei uma bateria de testes de SVG — borboletas, robôs, um pelicano andando de bicicleta, um controle de PS5. O Sonnet produziu resultados decentes. Formas reconhecíveis, escolhas de cores razoáveis, níveis de detalhe aceitáveis. Mas lado a lado com o Opus? A diferença é óbvia. O Opus gera SVGs com detalhes mais finos, melhor proporcionalidade e uso mais sofisticado de gradientes e sombras. Se fidelidade visual importa para o seu caso de uso, o Opus ainda é o vencedor claro aqui.

Raciocínio profundo com múltiplas etapas e ambiguidade. Quando uma tarefa tem especificações claras, o Sonnet 4.6 executa brilhantemente. Mas quando os requisitos são vagos e o modelo precisa fazer julgamentos — "construa algo que pareça premium" ou "trate os casos extremos apropriadamente" — o Opus toma decisões melhores. É a diferença entre um desenvolvedor pleno sólido e um arquiteto sênior. Ambos escrevem código funcional, mas o sênior faz escolhas melhores sobre o que construir e como estruturar.

Refatoração de código extenso. Apesar da janela de contexto de um milhão de tokens (que é genuinamente impressionante e funciona bem para leitura e análise de código), o Sonnet ocasionalmente perde coerência ao refatorar arquivos grandes. Ele pode renomear uma função em uma seção mas perder uma referência a ela 200 linhas depois. O Opus lida com isso de forma mais confiável. Não perfeitamente — nenhum modelo é perfeito — mas perceptivelmente melhor.

A diferença de alucinações diminuiu, mas não fechou. A Anthropic afirma que reduziu as alucinações no Sonnet 4.6, e meus testes confirmam isso. Ele alucina menos que o Sonnet 4.5. Mas ainda alucina mais que o Opus 4.6, particularmente com assinaturas de API e sintaxe específica de bibliotecas. Peguei-o inventando um método do Playwright que não existe em um teste. O Opus raramente comete esse tipo de erro.

Aqui está o framework ao qual cheguei após todos esses testes:

Use o Sonnet 4.6 quando:

• Velocidade importa mais que perfeição
• Você está iterando rapidamente e vai revisar a saída
• A tarefa é bem especificada com requisitos claros
• Custo é um fator (e sempre é, sejamos honestos)
• Você precisa de geração em tempo real ou quase real

Use o Opus 4.6 quando:

• A tarefa requer raciocínio arquitetural profundo
• A ambiguidade é alta e julgamentos importam
• Você precisa da máxima qualidade de código na primeira tentativa
• Fidelidade visual é crítica (SVGs, UI complexa)
• Você está fazendo o polimento final de algo importante

Esta não é uma decisão de um ou outro. É uma estratégia de portfólio. E esse é o verdadeiro insight que quero deixar com você.

A Janela de Contexto de Um Milhão de Tokens Muda Tudo (Quase)

Guardei isso para a segunda metade porque é a funcionalidade com as implicações mais significativas a longo prazo, mesmo ainda estando em beta.

Um milhão de tokens de contexto. Deixe-me colocar isso em perspectiva. O romance médio tem cerca de 80.000-100.000 palavras, ou aproximadamente 130.000-160.000 tokens. Um milhão de tokens equivale a aproximadamente seis romances completos. Ou, mais relevante: toda a sua base de código, toda a sua documentação, os requisitos do seu projeto, suas suítes de testes e suas configurações de deploy — tudo em uma única janela de contexto.

Testei isso com um projeto real: uma aplicação Laravel com 340 arquivos e aproximadamente 45.000 linhas de código. Carreguei toda a base de código no contexto do Sonnet 4.6 e pedi que identificasse potenciais vulnerabilidades de segurança em todo o projeto.

O modelo encontrou quatro problemas genuínos que eu não havia detectado em minha própria auditoria. Um era uma vulnerabilidade de mass-assignment em um model que estava lá há oito meses. Outro era uma rota de API com escopo inadequado que expunha dados de outros tenants em uma configuração multi-tenant.

Eu poderia ter encontrado isso com uma auditoria manual? Provavelmente — eventualmente. Mas a velocidade com que o modelo cruzou referências de arquivos, rastreou fluxos de dados entre controllers, models e middleware, e identificou os padrões de interação que criaram as vulnerabilidades? Isso me levaria dias de trabalho focado. O Sonnet fez em menos de três minutos.

As capacidades de planejamento estratégico são igualmente impressionantes. Alimentei o Sonnet 4.6 com uma especificação completa de projeto (12.000 palavras), a base de código existente e uma lista de novas funcionalidades. Ele gerou um plano de implementação que identificou corretamente cadeias de dependência que eu havia perdido, sugeriu uma ordem de execução que minimizava conflitos e sinalizou três funcionalidades que exigiriam migrações de banco de dados afetando dados de produção.

A limitação: a janela de contexto de um milhão de tokens está em beta, e notei uma queda de desempenho nas extremidades de contextos muito longos. Quando passei de 800.000 tokens, as respostas ficaram levemente menos precisas. Referências a código no "meio" do contexto (não no início ou no fim) às vezes eram vagas ou incorretas. Este é um problema conhecido com modelos de contexto longo e está melhorando, mas vale a pena saber.

Para o meu fluxo de trabalho, o ponto ideal prático é cerca de 500.000-600.000 tokens. O suficiente para conter uma base de código substancial com espaço para histórico de conversação. Só isso já é transformador para desenvolvimento baseado em agentes.

Minha Nova Estratégia de Modelos (E Quanto Custa)

Deixe-me dar números reais do meu último mês de trabalho de desenvolvimento, porque comparações abstratas são inúteis sem dados concretos.

Antes do Sonnet 4.6 (fluxo somente com Opus):

• Gasto mensal com API: ~$380
• Iterações médias por funcionalidade: 3-4
• Tempo de build por agente para tarefa de complexidade média: ~40 minutos
• Bugs em produção de código gerado por IA: 6-8 por mês

Após adotar a estratégia híbrida Sonnet/Opus:

• Gasto mensal com API: ~$220
• Iterações médias por funcionalidade: 5-6 (mais iterações, mesma qualidade)
• Tempo de build por agente para tarefa de complexidade média: ~25 minutos
• Bugs em produção de código gerado por IA: 4-5 por mês

O gasto caiu 42%. A contagem de bugs caiu em aproximadamente um terço. E eu na verdade estou iterando mais, o que significa detectar problemas mais cedo no ciclo de desenvolvimento ao invés de em produção.

O fluxo de trabalho na prática é assim:

1. Fase de exploração (Sonnet 4.6): Protótipo rápido, testar a abordagem, validar a arquitetura. Rápido e barato.
2. Fase de implementação (Sonnet 4.6): Desenvolver a funcionalidade com desenvolvimento dirigido por agentes. Múltiplas iterações.
3. Fase de revisão (Opus 4.6): Revisão final de código, análise de casos extremos, auditoria de segurança. Minucioso e preciso.
4. Deploy: Entregar com confiança.

As etapas 1 e 2 representam cerca de 70% do meu uso de API. Rodá-las no Sonnet em vez do Opus é de onde vem a economia. A etapa 3, onde a precisão mais importa, continua no Opus.

Vitórias rápidas se quiser tentar isso hoje:

• Cadastre-se nos créditos gratuitos de $25 do Kilo Code para testar o Sonnet 4.6 sem comprometer orçamento
• Rode seu prompt mais comum tanto no Sonnet quanto no Opus, compare lado a lado
• Experimente o LM Arena para comparações cegas — você pode se surpreender com a frequência em que não consegue distinguir qual é qual
• Se estiver usando Claude Code, experimente trocar seu modelo padrão para tarefas rotineiras

O Que Isso Significa Para os Próximos Seis Meses

Quero encerrar com algo em que tenho pensado desde que terminei esses testes.

A Anthropic essencialmente tornou inteligência de nível quase-Opus disponível na faixa de preço intermediária. Isso não é apenas uma atualização de produto — é um sinal de para onde a indústria está caminhando. A distância entre "o melhor modelo" e "o modelo acessível" está diminuindo. Daqui a seis meses, o modelo que custa $3 por milhão de tokens provavelmente vai igualar o que o modelo de $15 de hoje faz.

Para desenvolvedores, isso significa que a barreira para construir sistemas sofisticados alimentados por IA continua caindo. As arquiteturas de agentes que construo hoje — que exigem otimização cuidadosa de custos e roteamento de modelos — serão trivialmente baratas de rodar no próximo ano. Os pipelines de automação de navegador, os fluxos de geração de código, os sistemas de build multi-agente — tudo isso se torna acessível para desenvolvedores solo e equipes pequenas que não conseguiam justificar os custos de API antes.

Mas aqui está o ponto ao qual sempre volto: modelos mais baratos não fazem desenvolvedores melhores. Eles tornam mais código gerado por IA disponível, o que significa que a habilidade mais importante é a capacidade de avaliar, debugar e melhorar esse código. Os desenvolvedores que prosperarão nesse cenário não são os que melhor fazem prompts — são os que entendem o que o modelo está fazendo bem o suficiente para saber quando ele está errado.

Testei o Sonnet 4.6 por 72 horas. Ele me impressionou. Me economizou dinheiro. Mudou meu fluxo de trabalho. Mas no momento em que o peguei inventando um método inexistente do Playwright — o momento em que reconheci a alucinação porque eu conheço a API do Playwright — esse foi o lembrete.

O modelo é a ferramenta. Você ainda é o construtor.

Se está usando exclusivamente o Opus agora e não experimentou a abordagem híbrida, faça isso esta semana. Rode seu fluxo de trabalho padrão no Sonnet para as fases de exploração e build, mude para o Opus na revisão. Acompanhe seus custos e qualidade por duas semanas. Acho que você vai se surpreender com os números — assim como eu fiquei quando meu amigo me mandou aquele print e parei tudo para investigar.

Aquela landing page, aliás? Mostrei para um cliente. Ele achou que um designer humano tinha feito. O modelo que a gerou me custou cerca de quatro centavos.

Quanto seu fluxo de trabalho atual com IA custa — e o que você construiria de diferente se esse custo caísse pela metade?

🤝 Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura de tecnologia? Adoraria ajudar.

• 🔗 Fiverr (builds e integrações personalizadas): fiverr.com/s/EgxYmWD
• 🌐 Portfólio: mejba.me
• 🏢 Ramlit Limited (soluções empresariais): ramlit.com
• 🎨 ColorPark (design e branding): colorpark.io
• 🛡 xCyberSecurity (serviços de segurança): xcybersecurity.io