00:00:00Nenhum modelo Claude sozinho é suficiente. O Opus tem o raciocínio, mas acaba com os seus
00:00:04limites. O Sonnet é rápido, mas trava em decisões difíceis. E a resposta não é escolher um em vez
00:00:10do outro. É usar todos juntos. Agora, o Claude Code já faz isso até certo ponto.
00:00:14Ele orquestra entre os modelos por conta própria. Mas a Anthropic acabou de lançar algo que
00:00:18não só economiza tokens, mas também torna os modelos menores quase tão capazes quanto os maiores.
00:00:23Ao construir com o Claude, você pode ter notado isso. Sempre que você dá ao Opus uma tarefa
00:00:28e ele determina que não precisa de tanto esforço, ele a passa para o Sonnet ou Haiku e
00:00:32delega tarefas aos modelos menores para gerenciar o uso de tokens corretamente. Mas há um problema
00:00:37com essa abordagem. Como mencionamos no vídeo anterior, a Anthropic tem reduzido os limites de taxa,
00:00:42então, durante os horários de pico, sua janela de 5 horas se esgota mais rápido. E além disso, o Opus consome muitos
00:00:47tokens mesmo em tarefas simples, o que significa que usar o Opus faz seu limite de contexto encher mais rápido.
00:00:52A Anthropic decidiu mudar o jogo e lançou algo chamado
00:00:55estratégia Advisor (Consultor). A forma como essa estratégia funciona é que você dá o papel de executor ao modelo Sonnet
00:01:00e usa o Opus puramente como um consultor que só é consultado quando o executor realmente precisa.
00:01:05Há dois agentes envolvidos. O executor é o seu agente principal rodando no Sonnet e ele lida
00:01:10com todas as chamadas de ferramentas, mudanças de código e saídas para o usuário. O consultor roda no Opus e seu único
00:01:15trabalho é guiar o executor quando ele trava. O consultor nunca escreve código ou faz mudanças.
00:01:20Quando a Anthropic experimentou essa abordagem, descobriu que ela superou o Sonnet sozinho no
00:01:25SWE-bench. Eles viram que essa combinação superou o Sonnet sozinho tanto em desempenho quanto em custo.
00:01:31E custa significativamente menos do que rodar o Opus como agente principal porque o Opus só é invocado
00:01:36quando realmente importa, não em cada iteração. Agora, você pode pensar que já
00:01:40temos muitos frameworks para construir apps que são melhores e prontos para usar, então por que se dar ao trabalho?
00:01:45O motivo é que a maioria dos frameworks existentes não foi construída pensando em custo e eficiência de tokens.
00:01:50Embora eles façam o trabalho, eles falham na hora de fazer o Claude rodar por mais tempo
00:01:54e de forma mais eficiente, pois focam no desenvolvimento do app em vez de otimizar
00:01:59o uso de tokens. Com essa configuração, você pode construir um app funcional usando um modelo mais fraco, tornando
00:02:04todo o processo muito mais eficiente em tokens. E isso se conecta ao problema dos limites que mencionamos
00:02:09antes. Já fizemos um vídeo sobre os limites do Claude e dissemos para mudar para um modelo menor para
00:02:13durar mais. É assim que se conecta: o Sonnet consome muito menos tokens e exige menos esforço
00:02:19do que o Opus para realizar a mesma tarefa. O Opus é um modelo muito grande e poderoso, então consome muitos
00:02:24tokens mesmo para tarefas simples. O Sonnet consegue lidar com muitas dessas tarefas com mais eficiência. Então,
00:02:30usar o Opus apenas para preencher a lacuna de desempenho em decisões difíceis é onde está o real impacto.
00:02:35Você só invoca esse poder quando realmente precisa, não para cada tarefa individual. Isso torna o
00:02:40uso geral mais eficiente em tokens e permite que você faça mais dentro dos mesmos limites. Nós compartilhamos
00:02:45tudo o que descobrimos sobre criar produtos com IA neste canal, então, se quiser mais vídeos sobre isso,
00:02:50inscreva-se e fique de olho nos próximos vídeos. Queríamos testar como isso funciona na prática em um
00:02:55app que já foi construído usando o Sonnet. Para usar a estratégia dentro do Claude Code, configuramos o comando
00:03:00advisor com o Opus 4.6 como modelo consultor. Nosso agente principal era o executor, que eu já
00:03:05tinha definido como Sonnet, já que construí o app usando ele. O app deveria ter sincronização em tempo real e,
00:03:10embora mover e redimensionar elementos sincronizasse perfeitamente entre sessões, a exclusão não sincronizava nada. Tentamos
00:03:16depurar isso várias vezes apenas com o Sonnet, mas o problema persistia, não importa o quanto
00:03:20ele tentasse corrigir os erros. Então, após ativar o Opus como consultor, demos ao Claude o prompt
00:03:25descrevendo o problema e, como o Sonnet já havia falhado várias vezes, em vez de tentar
00:03:30outra vez sozinho, ele decidiu invocar o consultor desta vez. O consultor revisou a
00:03:34conversa até o momento para avaliar a situação. Ele forneceu as mudanças exatas que precisavam ser feitas, apontando
00:03:40onde a lógica de sincronização estava quebrando e o que especificamente precisava ser reestruturado. O modelo executor
00:03:45recebeu esse conselho e aplicou as correções diretamente, sem mais idas e vindas. Nós testamos
00:03:50em vários dispositivos para verificar a sincronização e vimos que o problema foi resolvido. Ambos os lados
00:03:55estavam refletindo as exclusões corretamente, como pretendido, mesmo se o usuário tivesse selecionado o item em um lado e o
00:04:00outro lado estivesse sendo deletado, o que não acontecia antes. Se tivéssemos tentado consertar isso usando o Sonnet
00:04:05sozinho, levaria mais rodadas de prompts, porque o Sonnet é inerentemente um
00:04:09modelo mais fraco e não é capaz o suficiente para lidar com lógica complexa por si só. Por outro lado, usar o Opus sozinho
00:04:15teria consumido muito mais tokens e provavelmente não seria tão rápido. Usar o Sonnet com o Opus
00:04:20como consultor tornou o processo muito mais eficiente. No geral, essa estratégia ajudou a depurar problemas de sincronização
00:04:25muito mais rápido do que antes. Mas antes de prosseguir, vamos ouvir uma palavra do nosso patrocinador, Juni da JetBrains.
00:04:30Se você é desenvolvedor, conhece a luta de alternar contexto entre seu terminal, IDE e pipelines de CI
00:04:36apenas para fazer as coisas. A maioria dos agentes de codificação prende você a um ambiente ou a um LLM específico
00:04:41e para por aí. O Juni CLI é diferente. É um agente de codificação agnóstico de LLM que funciona em qualquer lugar. Seu
00:04:47terminal, seu IDE, GitHub, pipelines de CI/CD, até no seu gerenciador de tarefas. Um único agente em todo lugar. Delegue
00:04:54trabalho real a ele: escrever testes, construir backends, refatorar, automatizar revisões de código a cada commit.
00:04:59No momento, a JetBrains está com um programa de acesso antecipado gratuito, incluindo US$ 50 em créditos do Gemini para testar o
00:05:04agente, além de suporte BYOK para que você use qualquer modelo que preferir. Acesso total a todos os recursos, acesso antecipado
00:05:10a novos recursos e suporte direto da equipe de desenvolvimento que está criando o produto. É simplesmente melhor com o Juni.
00:05:15Clique no link no comentário fixado para participar de graça. Agora, queríamos testar se o Sonnet realmente
00:05:20consulta o consultor para mudanças importantes de UI. Tínhamos um aplicativo construído anteriormente e queríamos
00:05:25transformar sua UI para uma biblioteca diferente. Além disso, queríamos fazer várias mudanças de UI de uma
00:05:31só vez, o que normalmente não é recomendado, mas queríamos ver como o modelo menor se comporta em coordenação
00:05:36com o maior em uma tarefa grande. Primeiro, ele acessou a UI atual usando o MCP do Playwright.
00:05:41Assim que entendeu o layout, em vez de pular direto para as mudanças de código, ele consultou o consultor
00:05:46para determinar a melhor abordagem, porque era uma mudança crítica importante que poderia quebrar o app se
00:05:50fosse mal administrada. O consultor relatou que a biblioteca que escolhemos como nova e a que
00:05:55já era usada no projeto tinham problemas de versão. Então, antes de qualquer trabalho de UI, o Claude precisava
00:06:00resolver isso primeiro. O Sonnet lidou com isso primeiro, executou vários comandos para garantir que as dependências
00:06:04fossem aplicadas corretamente e então verificou o estado atual da UI pelo Playwright para confirmar que o app
00:06:09ainda rodava corretamente, sem erros no cliente. Resolvidas as dependências, ele começou a fazer
00:06:14as mudanças sugeridas pelo consultor, trabalhando em cada componente um por um e efetivamente
00:06:18redesenhando o app como um todo. A UI que ele criou era muito mais interativa e parecia significativamente
00:06:23mais polida do que antes. Ainda tinha alguns problemas, mas a melhora geral foi clara. Mas aqui
00:06:27é onde a limitação apareceu. Todo o processo levou cerca de 31 minutos. O Opus sozinho teria
00:06:32feito isso muito mais rápido, pois é melhor em orquestrar tarefas identificando o que pode rodar em
00:06:37paralelo e executando-as ao mesmo tempo. O Sonnet, sendo um modelo menor, lidou com tudo sequencialmente,
00:06:43sem dividir o trabalho em subagentes paralelos. Para um app que nem era tão complexo,
00:06:4831 minutos é mais tempo do que deveria ter sido. Ele também lida com mudanças menores por conta própria, sem
00:06:53envolver o consultor, o que é o comportamento correto para pequenos ajustes. Mas para mudanças em larga escala em
00:06:58todo um app como este, é melhor usar o Opus diretamente, pois isso economizará significativamente
00:07:03mais tempo e esforço. Agora, queríamos testar se ele implementa um recurso completamente novo em uma
00:07:08base de código existente de forma adequada. Tínhamos um app já construído e queríamos adicionar outra página com um
00:07:13recurso diferente. Demos a ele um prompt descrevendo o que queríamos e, desta vez, esperávamos totalmente
00:07:17que ele usasse o consultor por não ser uma tarefa simples, mas ele foi em frente e implementou
00:07:22as mudanças inteiramente sozinho, sem consultar o consultor em nenhum momento. Ele tratou tudo como
00:07:27um trabalho de implementação rotineiro, o que claramente não era, dado o escopo do recurso. Quando testamos o
00:07:31aplicativo, encontramos vários problemas. Se modificássemos algo e apertássemos o botão de rodar, mudanças como
00:07:37atualizações de cabeçalho ou ajustes de cor também eram refletidas em componentes fora do painel de visualização,
00:07:41o que não deveria acontecer. Além disso, queríamos que sincronizasse diretamente em vez de exigir que apertássemos
00:07:46rodar novamente após cada mudança. Então, enviamos outro prompt e dissemos para ele usar o consultor para corrigir
00:07:51esses problemas. Após o nosso prompt, ele primeiro invocou o agente consultor. O consultor analisou a
00:07:56implementação e identificou o que realmente estava causando ambos os problemas: a escolha
00:08:00errada de componentes. Ele detalhou o que precisava mudar e por que a abordagem original tinha introduzido aqueles
00:08:06problemas em primeiro lugar. O executor seguiu essa orientação e a aplicou em todo o app. Quando
00:08:10testamos novamente, o streaming funcionou corretamente. Todas as mudanças eram refletidas imediatamente enquanto editávamos,
00:08:16sem precisar apertar rodar após cada modificação. O problema das mudanças vazando para outros componentes
00:08:20também foi resolvido e tudo atualizava corretamente dentro dos limites certos. Então, há momentos
00:08:25em que funciona exatamente como pretendido, mas outras vezes o executor presume que uma tarefa é pequena o suficiente e
00:08:30decide não consultar o consultor. Nesses casos, muitas vezes você precisa dar um empurrão para que ele siga
00:08:35o fluxo de trabalho pretendido. O modelo nem sempre julga a complexidade de uma tarefa da mesma forma que
00:08:40você, e quando ele julga mal, você acaba com bugs que o consultor teria detectado desde o início. Além disso,
00:08:44se estiver gostando do nosso conteúdo, considere clicar no botão de hype, pois isso nos ajuda a criar mais
00:08:49conteúdo como este e alcançar mais pessoas. Com estado distribuído em tempo real envolvido, essa
00:08:54abordagem ainda precisou de várias rodadas de prompts antes que tudo estivesse funcionando corretamente. A
00:08:58estratégia ajudou, mas tem um teto que você deve entender antes de se comprometer com ela para um projeto.
00:09:02Para aplicações de escala simples a média, a estratégia Advisor pode economizar várias rodadas
00:09:07de idas e vindas que você gastaria tentando forçar o Sonnet além dos seus limites
00:09:11sozinho. Se o que você está construindo exige raciocínio profundo ocasional, mas principalmente
00:09:16implementação direta, esta é uma estrutura genuinamente boa para isso. Você pode construir mais dentro dos seus limites de tokens
00:09:20sem precisar vigiar o modelo em cada decisão ou recorrer ao Opus em toda a sessão.
00:09:25Para apps complexos com muitas dependências conectadas ou múltiplos pontos de falha, é melhor apenas
00:09:30usar o Opus diretamente como seu agente principal. Mesmo quando o Sonnet segue a orientação do consultor corretamente,
00:09:36ele ainda pode escolher o caminho de implementação errado porque não tem a profundidade de raciocínio para
00:09:40avaliar múltiplas abordagens ao mesmo tempo e pesar as consequências futuras. O consultor ajuda a diminuir
00:09:45essa lacuna, mas não a fecha totalmente. Nesses casos, o vai e vem pode custar mais tempo
00:09:50do que rodar o Opus desde o início teria custado. Portanto, essa estratégia é útil quando você está trabalhando com
00:09:54limites de tokens apertados e a aplicação não exige raciocínio de nível Opus em cada etapa. Se
00:09:58ambas as condições forem verdadeiras para o que você está construindo, vale a pena configurar. Isso nos traz
00:10:03ao fim deste vídeo. Se você quiser apoiar o canal e nos ajudar a continuar fazendo vídeos como este,
00:10:08pode fazer isso usando o botão de Valeu Demais abaixo. Como sempre, obrigado por assistir e nos
00:10:12vemos no próximo.