Claude Code /advisor Command: Um Segundo Cérebro para Modelos Travados
Passei um sábado inteiro tentando quebrar o novo comando /advisor do Claude Code.
Não no sentido de "encontrar o bug e abrir um ticket." Mais no sentido de: "Já me queimei vezes o suficiente com slash commands novos e brilhantes para não confiar em nenhum deles antes de jogar código de produção feio em cima." Meu campo de testes foi um serviço de cobrança que venho refatorando há semanas — uma aplicação Laravel 11 com o tipo de casos extremos que expõe cada fraqueza em um modelo de IA para programação. Upgrades proporcionais. Downgrades no meio do ciclo. Lógica de dunning que precisa sobreviver a uma falha parcial do webhook do Stripe.
O resultado me surpreendeu. Não porque o /advisor me salvou de uma catástrofe — não salvou. Mas porque ele capturou dois problemas que eu vinha encarando por três dias sem conseguir ver. Uma falha lógica na janela de prorrata e um bug sutil de fuso horário no cálculo de renovação. O Sonnet 4.6 estava rodando como meu executor principal. Quando ele chegou ao padrão de travamento na minha terceira passagem, chamou o Opus 4.6 via /advisor e voltou com uma análise de dois parágrafos que soava como a revisão de código de um engenheiro sênior.
Foi aí que percebi que esse comando não é realmente sobre conselhos. É sobre a Anthropic construindo um andaime para o Mythos.
Deixa eu explicar o que quero dizer — e por que o slash command /advisor pode ser a funcionalidade mais importante que o Claude Code lançou este trimestre, mesmo que a maioria dos desenvolvedores o descarte como uma atualização menor de qualidade de vida.
O que /advisor realmente faz (e o que não faz)
O comando /advisor permite configurar um modelo secundário que é invocado quando seu modelo principal enfrenta dificuldades. Esse é o resumo executivo. A realidade é mais matizada, e a nuance importa.
Veja como funciona a configuração atual. Você executa /advisor dentro do Claude Code, escolhe um modelo da lista (por enquanto Sonnet 4.6 ou Opus 4.6 — sem outras opções, sem endpoints personalizados, sem Haiku), e a partir daí o Claude Code tem a capacidade de invocar esse modelo de forma autônoma quando decide que precisa de uma segunda opinião. Você não chama o advisor manualmente. Você não digita "pergunte ao advisor sobre isso." O modelo principal toma a decisão de forma autônoma com base em sinais de contexto.
Essa última parte me pegou de surpresa na primeira vez. Fiquei esperando um prompt ou um diálogo de confirmação. Não existe nenhum. A chamada ao advisor acontece silenciosamente, no meio de uma resposta, e o conselho é incorporado de volta ao contexto da sessão como se sempre tivesse estado lá.
Três coisas que você precisa entender sobre como isso realmente funciona:
O advisor tem o contexto conversacional completo. Quando o modelo principal chama /advisor, o modelo secundário recebe o transcript completo — sua solicitação original, cada chamada de ferramenta, cada arquivo lido, cada saída de comando, cada etapa de raciocínio. Sem parâmetros. Sem filtragem. Sem cherry-picking. Ele vê o que seu modelo principal viu, na mesma ordem, com as mesmas restrições.
O advisor não pode tocar o mundo exterior. Sem acesso ao sistema de arquivos. Sem comandos shell. Sem requisições web. Sem servidores MCP. O advisor existe puramente para raciocinar sobre o histórico de conversação e retornar orientação. Este é um limite arquitetônico rígido, não uma permissão que você pode ativar.
O conselho se torna parte da memória compartilhada. Uma vez que o advisor responde, sua análise persiste no contexto da sessão. Chamadas posteriores ao advisor veem conselhos anteriores. Se os resultados empíricos contradizem o que o advisor recomendou, o Claude Code traz o conflito à superfície em vez de substituir silenciosamente a orientação. Você obtém um momento explícito de "o advisor disse X, mas a saída do teste mostra Y — devo consultar novamente?"
Esse terceiro comportamento foi o que eu não esperava, e é o que mudou minha opinião sobre a funcionalidade.
Os quatro gatilhos que chamam o advisor
Passei a primeira hora de testes tentando descobrir quando o Claude Code realmente recorre ao advisor. A documentação é escassa. O comportamento é parcialmente emergente. Então executei uma série de cenários controlados e observei os logs.
Quatro padrões ativam uma chamada ao advisor de forma confiável. Se você entender esses padrões, saberá se o /advisor vale a pena ativar para o seu fluxo de trabalho ou se vai simplesmente ficar consumindo tokens de contexto que nunca usa.
Gatilho 1: Antes de escrever ou interpretar de forma substancial. Quando o modelo está prestes a escrever um bloco significativo de código, gerar um novo arquivo ou fazer um salto interpretativo de requisitos para implementação, ele pausa e pede ao advisor uma verificação de sanidade primeiro. Esse é o padrão de "medir duas vezes, cortar uma." Tarefas reativas simples — renomear uma variável, corrigir um erro de digitação, ajustar uma margem — pulam isso completamente.
Gatilho 2: Na linha de chegada percebida. Quando o modelo principal acredita que a tarefa está completa, chama o advisor para verificar a saída antes de declarar sucesso. Isso capturou um bug no meu código de cobrança que o Sonnet 4.6 tinha se convencido de que estava resolvido. O advisor sinalizou um caso extremo ausente na lógica de prorrata, e o Sonnet voltou atrás e corrigiu sem que eu dissesse uma palavra.
Gatilho 3: Erros recorrentes ou loops que não convergem. Se o modelo tenta a mesma correção três vezes e os testes continuam falhando, ou se está alternando entre duas abordagens incompatíveis, o advisor é chamado. Esse é o padrão que mais me importa porque é o que costumava consumir toda a minha tarde. Você conhece o loop — o modelo corrige uma coisa, quebra outra, corrige essa, regride a primeira, e eventualmente você precisa intervir manualmente e desemaranhar toda a bagunça.
Gatilho 4: Checkpoints em tarefas de múltiplas etapas. Para qualquer tarefa com múltiplas fases (o tipo em que o Claude Code constrói uma lista de tarefas no início), o advisor é chamado pelo menos duas vezes. Uma vez antes de confirmar trabalho substancial. Uma vez na conclusão. Essa é a rede de segurança padrão para os fluxos de trabalho onde as coisas mais frequentemente dão errado.
O que não ativa uma chamada ao advisor? Ajustes menores de UI. Refatorações únicas. Correções reativas para problemas diretos. Qualquer coisa sobre a qual o modelo principal está confiante. O sistema é deliberadamente conservador — não quer queimar tokens em problemas que não precisam de uma segunda opinião.
Mas há um problema com esse conservadorismo. Se seu modelo principal está muito confiante — e qualquer um que tenha usado o Sonnet 4.6 por tempo suficiente sabe que ele pode ser — o advisor não será chamado quando deveria. O julgamento para invocar o advisor vive dentro do mesmo modelo cujo julgamento você está tentando auditar. Essa é uma tensão de design que acho que ainda não está completamente resolvida, e voltarei a ela na seção de "papo reto."
Por ora, deixa eu mostrar como as combinações de modelos se parecem na prática.
As três combinações que testei (e qual vence)
Há realmente apenas três formas de configurar o /advisor agora, e executei as três na mesma refatoração de cobrança ao longo do fim de semana. Veja o que encontrei.
Combinação 1: Sonnet 4.6 principal + Opus 4.6 advisor
Esta é a combinação para a qual a Anthropic parece estar direcionando os usuários, e após testar, entendo o porquê. O Sonnet 4.6 roda como seu modelo de execução. É rápido, é barato, é bom o suficiente para 85% do trabalho de programação que faço no dia a dia. Quando trava, o Opus 4.6 entra como advisor e aplica seu raciocínio mais profundo ao problema.
A matemática de custo aqui é genuinamente interessante. O Sonnet 4.6 custa aproximadamente a metade do que o Opus 4.6 custa por milhão de tokens. O advisor é invocado apenas em gatilhos específicos, então você não está pagando taxas de Opus para toda a sessão — apenas nos momentos de travamento. Na minha sessão de sábado, executei cerca de 42 rodadas de Sonnet 4.6 com exatamente 6 chamadas ao advisor para o Opus 4.6. A divisão de tokens ficou mais barata do que executar o Opus 4.6 como modelo principal para a mesma sessão, com uma margem que importaria em escala.
Em termos de qualidade? Obtive resultados comparáveis ao que uma sessão pura de Opus 4.6 teria me dado, porque cada momento que importou teve o Opus no loop de qualquer forma.
Combinação 2: Opus 4.6 principal + Sonnet 4.6 advisor
Esta é a combinação invertida, que testei principalmente por curiosidade. O resultado: não é ótimo. O Sonnet 4.6 é um modelo capaz, mas quando o Opus 4.6 já está lutando, pedir ao Sonnet para auditar o raciocínio é como pedir a um engenheiro júnior para revisar a decisão de arquitetura de um engenheiro sênior. As chamadas ao advisor voltavam com concordância ("sua abordagem parece correta") ou sugestões superficiais que o Opus já havia considerado e descartado.
Não recomendo essa configuração. Se o Opus é seu modelo principal, é melhor gerar um subagente com seu próprio context window para lidar com os momentos de travamento — que é, aliás, a abordagem que uso por padrão quando executo o Opus como executor.
Combinação 3: Opus 4.6 principal + Opus 4.6 advisor
Sim, você pode configurar o mesmo modelo como principal e advisor. Não, não é inútil — mas não é tão poderoso quanto as combinações que usam modelos distintos, porque você perde o efeito de olhos frescos. A vantagem do advisor vem em parte de abordar o problema de um ângulo diferente. Quando o advisor é literalmente o mesmo modelo com os mesmos vieses, a perspectiva nova encolhe.
Dito isso, essa combinação ainda superou o Opus sem supervisão no meu teste de erros recorrentes, porque a chamada ao advisor força uma pausa reflexiva que o modelo principal não teria feito sozinho. O passo metacognitivo importa mesmo quando a cognição vem da mesma fonte.
O vencedor para a maioria dos desenvolvedores: Sonnet 4.6 principal, Opus 4.6 advisor. Mais barato que o Opus puro. Mais inteligente que o Sonnet puro. O fluxo de trabalho mais limpo que testei.
Percorrendo uma chamada real ao advisor, passo a passo
Deixa eu te mostrar exatamente como isso se parece na prática, porque a descrição abstrata não captura a experiência. Vou usar o cenário do bug de cobrança porque foi meu caso de teste mais limpo.
Passo 1: Configurar o advisor.
Dentro do Claude Code, executei o comando:
/advisor
O prompt voltou perguntando qual modelo configurar. Selecionei Opus 4.6. O Claude Code confirmou: "Advisor configurado. O Opus 4.6 será consultado para decisões complexas e verificações de conclusão de tarefas." Só isso. Sem configuração adicional. Sem parâmetros de amostragem. Sem personalização do prompt.
Passo 2: Iniciar a tarefa principal.
Pedi ao Claude Code (com Sonnet 4.6 como principal) para auditar a lógica de prorrata na minha classe SubscriptionBillingService e corrigir quaisquer bugs que encontrasse. O Sonnet 4.6 leu o arquivo, rastreou o fluxo por três classes dependentes e propôs uma correção para o que identificou como um erro de deslocamento por um no cálculo de dias proporcionais.
Passo 3: Sonnet aplica a correção e executa os testes.
A correção passou em 14 dos 16 testes existentes. Dois testes falharam — ambos relacionados ao tratamento de fuso horário em limites de renovação. Sonnet tentou uma segunda correção. Os mesmos dois testes falharam. Tentou uma terceira abordagem. O mesmo padrão de falha.
É aqui que o gatilho de erro recorrente dispara.
Passo 4: Sonnet chama /advisor.
A saída do console tornou a chamada explícita:
[advisor invoked: recurring test failure on timezone-sensitive cases]
Sem interação da minha parte. O Sonnet fez a chamada de forma autônoma. O Opus 4.6 recebeu o transcript completo — minha solicitação original, o conteúdo do arquivo, as falhas dos testes, as três tentativas de correção — e retornou uma análise estruturada.
Passo 5: O conselho retorna.
A resposta do Opus 4.6 identificou dois problemas que o Sonnet havia perdido. Primeiro: a lógica de prorrata estava usando o fuso horário local do servidor em vez do fuso horário de assinatura do usuário, o que significava que renovações próximas à meia-noite UTC eram calculadas no período de cobrança errado. Segundo: os fixtures de teste que o Sonnet havia atualizado estavam eles mesmos errados, razão pela qual as correções do Sonnet continuavam parecendo corretas mas os testes continuavam falhando — os testes estavam validando o bug, não a correção.
Nenhum dos dois problemas era óbvio na análise solo do Sonnet. Ambos eram óbvios em retrospecto assim que o Opus os apontou.
Passo 6: Sonnet integra o conselho.
O Sonnet 4.6 não apenas copiou a resposta do advisor textualmente. Ele tomou a orientação, reescreveu a lógica de prorrata para usar o fuso horário do usuário e, em seguida, independentemente sinalizou o problema do fixture de teste para minha revisão — "O advisor observou que os fixtures podem estar validando comportamento incorreto. Recomendo revisar tests/Unit/ProrationTest.php linhas 84-110 antes de modificá-los, pois isso muda a semântica dos testes."
Essa última parte é o comportamento que me convenceu do /advisor. O Sonnet não aplicou o conselho cegamente. Ele parou no lugar onde o conselho tinha implicações sobre as quais eu deveria ter voz.
Passo 7: Verificação.
Aprovei a revisão do fixture. O Sonnet atualizou os testes, reexecutou a suite, e todos os 16 testes passaram. Tempo total da primeira correção com falha até a execução de testes com sucesso: menos de quatro minutos. Tempo de depuração manual que teria gasto no mesmo problema, com base em quanto tempo já estava travado: provavelmente mais duas horas.
As dicas pro que ninguém está falando ainda
Algumas coisas que aprendi nos testes que não constam na documentação do anúncio.
Dica 1: Chamadas ao advisor aparecem no ledger de tokens, mas como um item separado. Você pode ver exatamente quanto o advisor custou versus o modelo principal. Isso é surpreendentemente útil para calibrar se a funcionalidade está valendo a pena em qualquer projeto específico. Estou rastreando a proporção em meus projetos de teste e provavelmente publicarei os dados em um artigo de acompanhamento.
Dica 2: O advisor persiste entre operações /compact. Se você compactar sua conversa para liberar contexto, a orientação anterior do advisor sobrevive à compactação. Este é um detalhe pequeno com grandes implicações para sessões longas — seu advisor efetivamente se torna uma camada de conhecimento cumulativo.
Dica 3: Você pode reexecutar /advisor para trocar modelos no meio de uma sessão. Não percebi isso no início, mas você pode trocar sua configuração de advisor no meio de uma sessão sem reiniciar. Usei isso para passar de Opus-como-advisor para um Opus-como-advisor fresco após um /compact para resetar o estado acumulado do advisor.
Dica 4: O gatilho do advisor pode ser ajustado. Embora você não possa forçar uma chamada, você pode fazer com que o modelo principal seja mais propenso a invocar o advisor sendo explícito no seu prompt. Frases como "verifique isso com o advisor antes de confirmar" ou "se travar, consulte o advisor" aumentaram mensurável mente a taxa de chamadas nos meus testes. Não é garantia — mas é uma alavanca útil.
Dica 5: Fique atento ao comportamento de loop do advisor. Em um teste, o Sonnet 4.6 chamou o Opus 4.6 três vezes seguidas para o mesmo problema, cada vez recebendo um conselho ligeiramente diferente e cada vez se sentindo menos certo sobre sua direção. Esse é o modo de falha a observar. Se você vir o advisor sendo chamado repetidamente sem progresso, intervenha manualmente. A camada metacognitiva é valiosa, mas não é um substituto para o julgamento humano quando o modelo está genuinamente perdido.
Papo reto: Por que ainda prefiro subagentes para fluxos de trabalho com Opus
Aqui vem a parte honesta. Para meu fluxo de trabalho diário real — onde executo Opus 4.6 como modelo principal em arquiteturas de agentes complexas — ainda prefiro subagentes com context windows independentes ao /advisor. Deixa eu explicar por quê, porque o tradeoff importa.
Quando gero um subagente, esse agente começa com um contexto limpo. Sem conversa acumulada. Sem enquadramento enviesado das tentativas anteriores do modelo principal. Apenas o prompt que forneço e as ferramentas que autorizo. Essa limpeza frequentemente faz a diferença entre orientação útil e conselho que apenas reflete de volta os pontos cegos do modelo principal.
O comando /advisor, por outro lado, alimenta o transcript completo ao advisor toda vez. Se o modelo principal está travado porque está enquadrando o problema errado, o advisor vê o mesmo enquadramento errado e pode ou não escapar dele. O Opus é melhor em escapar de armadilhas de enquadramento do que o Sonnet, razão pela qual a combinação Sonnet-principal + Opus-advisor funciona tão bem — o Opus traz potência suficiente para reenquadrar. Mas quando o Opus é seu modelo principal e o enquadramento é o problema, o advisor pode ser puxado para a mesma armadilha.
Testei isso diretamente. Dei ao Opus 4.6 um problema de arquitetura deliberadamente mal enquadrado e configurei o Opus 4.6 como advisor. O advisor concordou com o enquadramento. Em seguida, gerei um subagente Opus 4.6 fresco com apenas os requisitos originais (sem transcript) e fiz a mesma pergunta. O subagente reenquadrou o problema imediatamente e propôs uma solução diferente.
Mesmo modelo. Mesmo problema. Resultados diferentes com base na frescura do contexto.
Então aqui está minha regra prática real: use /advisor quando seu modelo principal for Sonnet e você quiser uma rede de segurança do Opus. Use subagentes quando seu modelo principal for Opus e você quiser um raciocínio paralelo genuíno. Use ambos quando estiver trabalhando em algo de alto risco.
E seja honesto consigo mesmo sobre em qual modo você está. Os padrões da funcionalidade são inteligentes, mas não são mágica.
Por que /advisor é realmente sobre Mythos
Agora a parte para a qual venho construindo.
Não acho que o /advisor existe porque a equipe do Claude Code queria lançar uma camada metacognitiva para Sonnet e Opus. Acho que o /advisor existe porque a Anthropic está preparando a infraestrutura para o Mythos — o modelo que começou a vazar em conversas públicas há algumas semanas e sobre o qual já escrevi em a análise do vazamento do Claude Mythos — e eles precisavam de uma maneira de tornar um modelo de alto custo e alto desempenho economicamente viável dentro do Claude Code.
Pense nisso. Se o Mythos chegar ao ponto de preço que os vazamentos sugerem — significativamente acima do Opus 4.6 — executá-lo como modelo principal para uma sessão inteira será proibitivo para a maioria dos desenvolvedores. Mesmo para trabalho de agência, as margens não farão sentido em cada tarefa. Então como você dá aos usuários acesso ao poder do Mythos sem obrigá-los a pagar as tarifas do Mythos por cada token?
Você os deixa configurá-lo como advisor.
Imagine a combinação: Sonnet 4.6 como seu modelo de execução, rodando rápido e barato para a maioria dos seus tokens. Mythos como seu advisor, invocado apenas nos momentos críticos — antes de grandes commits, quando os testes continuam falhando, quando o modelo está prestes a fazer um salto interpretativo. Você obtém julgamento de nível Mythos nas decisões que mais importam, a uma fração do custo de executar o Mythos como modelo principal.
Esse é o padrão. /advisor é o andaime. A combinação Sonnet/Opus que temos hoje é o teste beta da combinação Sonnet/Mythos que está por vir.
Posso estar errado sobre isso. É possível que o /advisor seja apenas uma funcionalidade independente e que a integração do Mythos se pareça completamente diferente. Mas as escolhas de arquitetura contam uma história. A lista de modelos permitidos rígida (atualmente dois modelos). O compartilhamento automático de contexto. O comportamento de detecção de conflitos que traz à superfície os desacordos do advisor em vez de deferir a eles. Todas essas são decisões de design que fazem perfeito sentido se seu objetivo final é um sistema de modelos em camadas onde o modelo de nível mais alto é caro o suficiente para que você só queira consultá-lo nos problemas mais difíceis.
E se eu estiver certo sobre isso, os desenvolvedores que aprenderem o /advisor agora terão uma enorme vantagem quando o Mythos chegar. Os padrões de fluxo de trabalho que você construir em torno de Sonnet-principal + Opus-advisor vão se transferir quase diretamente para Sonnet-principal + Mythos-advisor, com apenas a configuração mudando. Os hábitos de prompt, a consciência dos gatilhos, o framework de decisão subagente-versus-advisor — tudo se transfere.
Se você quiser uma análise mais profunda do que o Mythos pode trazer, escrevi sobre as implicações em meu mergulho profundo no Mythos sobre autonomia de modelos. Mas a versão curta: seja o que for que o Mythos se mostre ser, será caro, e o /advisor é como você vai acessá-lo sem quebrar.
O que eu recomendaria que você fizesse hoje
Se você já está no Claude Code e usa o Sonnet 4.6 para a maior parte do seu trabalho, ative o /advisor com o Opus 4.6 como advisor agora mesmo. Execute-o em um projeto real esta semana. Preste atenção em com que frequência o advisor é chamado e que tipos de problemas o ativam. Esse reconhecimento de padrões é o valor real — não as primeiras vezes em que ele te salva de um bug, mas a compreensão gradual de quando seu modelo provavelmente precisa de uma segunda opinião.
Se você está executando o Opus 4.6 como modelo principal, ainda recomendaria ativar o /advisor com Opus como advisor, mas em paralelo com seus fluxos de trabalho de subagentes existentes. Não substitua subagentes. Aumente-os. Use o /advisor para as segundas opiniões leves e inline e subagentes para o raciocínio paralelo mais pesado.
Se você ainda não atualizou para Sonnet 4.6 ou Opus 4.6, faça isso primeiro. O comando advisor requer eles. Modelos mais antigos não estão na lista de permitidos e não estarão — a funcionalidade é explicitamente projetada para a geração atual.
Mais uma coisa. Se você está na minha lista de e-mail ou acompanha meu blog, vou rastrear os padrões de uso do /advisor nas próximas semanas e publicar os dados. Proporções de custo, frequências de gatilho, resultados reais em projetos reais. O tipo de dado que te diz se essa funcionalidade merece seu lugar no seu fluxo de trabalho ou se é um nice-to-have que você pode ignorar. Se você quiser esses dados antes de serem públicos, a melhor forma de obtê-los é começar a executar seus próprios testes agora — porque quando eu publicar meus resultados, o Mythos provavelmente estará a semanas de mudar completamente a equação.
O comando /advisor não é a maior funcionalidade que o Claude Code lançou este ano. Pode nem ser a mais útil em qualquer dia dado. Mas é a mais estruturalmente importante, porque é a primeira vez que a Anthropic construiu infraestrutura explícita para colaboração multi-modelo dentro de uma única sessão, e essa infraestrutura vai importar enormemente assim que o nível de modelos acima do Opus realmente existir.
O bug de cobrança que levei três dias para encontrar? Sonnet e Opus o encontraram em quatro minutos de análise assistida pelo advisor. Isso não é o fim da história. É o começo de um padrão de fluxo de trabalho que vou usar por anos.
Comece a construir o hábito agora. Você vai ficar feliz por ter feito isso quando o próximo modelo chegar.
Perguntas frequentes
O que é o slash command /advisor do Claude Code?
O slash command /advisor permite configurar um modelo Claude secundário que é invocado automaticamente pelo seu modelo principal quando encontra decisões complexas, erros recorrentes ou checkpoints de conclusão de tarefas. Atualmente suporta apenas Sonnet 4.6 e Opus 4.6. O advisor recebe o transcript completo da conversa e retorna orientação que é incorporada ao contexto compartilhado da sessão.
Qual combinação de modelos devo usar com /advisor?
Para a maioria dos desenvolvedores: use Sonnet 4.6 como modelo principal e Opus 4.6 como advisor. Essa combinação fornece a velocidade e eficiência de custo do Sonnet para trabalho rotineiro enquanto reserva o raciocínio mais profundo do Opus para os momentos que importam. Testei todas as três combinações viáveis e esta produziu a melhor relação custo-qualidade em tarefas de refatoração reais.
O /advisor funciona com subagentes?
Sim, mas eles servem a propósitos diferentes. O /advisor alimenta o transcript completo a um modelo secundário inline, enquanto subagentes rodam com context windows limpos e independentes. Use /advisor quando seu modelo principal for Sonnet. Use subagentes quando seu modelo principal for Opus e você precisar de uma perspectiva fresca livre do enquadramento do modelo principal.
O advisor pode acessar arquivos ou executar comandos?
Não. O advisor não tem acesso ao sistema de arquivos, shell, web ou servidores MCP. Ele apenas raciocina sobre o histórico de conversação que recebe do modelo principal. Este é um limite arquitetônico rígido na implementação atual, não uma permissão configurável.
O /advisor é mais barato do que executar o Opus 4.6 como modelo principal?
Nos meus testes, sim — uma sessão de 42 rodadas de Sonnet 4.6 com 6 chamadas ao advisor do Opus 4.6 ficou mais barata do que executar o Opus 4.6 como modelo principal para a mesma carga de trabalho. A economia vem de usar o modelo mais barato para a maioria dos tokens e pagar taxas premium apenas nas invocações do advisor.
Vamos trabalhar juntos
Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria te ajudar.
- Fiverr (builds e integrações personalizadas): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e branding): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
