Claude Opus 4.8: A única configuração que decide tudo

Claude Opus 4.8: A única configuração que decide tudo

O que me convenceu sobre o Claude Opus 4.8 não foi o gráfico de benchmarks. Foi uma refatoração que eu vinha adiando.

Eu tinha uma classe de serviço em Laravel que, em quatro meses de acúmulo de funcionalidades, tinha crescido até virar um monstro de 600 linhas — o tipo de arquivo onde você altera um método e três testes não relacionados ficam vermelhos. Com o Opus 4.7, eu tinha tentado duas vezes fazer o modelo desemaranhar o código. Nas duas vezes, ele desistiu no meio do caminho, declarou o trabalho "substancialmente concluído" e me deixou com um trait extraído pela metade e uma suíte de testes quebrada. Típico 4.7. Confiante, e depois silenciosamente preguiçoso.

Na manhã do dia 28 de maio, o dia em que o Claude Opus 4.8 foi lançado, apontei-o para o mesmo arquivo. Mesmo prompt. Mesmo repositório. Coloquei o nível de esforço em max, apertei enter e fui fazer café.

Quando voltei, ele tinha extraído três classes coesas, reescrito os bindings no service provider, atualizado cada teste, executado a suíte, encontrado dois edge cases reais que ele havia introduzido e corrigido — sem perguntar. Depois me disse, com toda naturalidade: "Estou razoavelmente confiante na extração, mas não mexi na camada de cache porque o comportamento original ali era ambíguo e eu não quis adivinhar." Essa última frase é toda a história deste lançamento. Não apenas que ele terminou o trabalho. Mas que me disse exatamente onde não mexeu.

Já estou usando o Opus 4.8 como minha ferramenta diária há mais de uma semana — trabalho com clientes, o pipeline de conteúdo deste blog, um projeto SaaS paralelo pela metade. Este é o veredito real além do gráfico da Anthropic, e a única configuração que decide se você termina amando ou amaldiçoando este modelo.

O que a Anthropic realmente lançou em 28 de maio

O Claude Opus 4.8 entrou no ar em 28 de maio de 2026, construindo diretamente sobre o Opus 4.7. A própria abordagem da Anthropic no anúncio oficial é incomumente contida: ele se constrói sobre o 4.7 com "julgamento mais afiado, mais honestidade sobre seu próprio progresso e a capacidade de trabalhar independentemente por mais tempo que seus predecessores."

Duas coisas práticas importam antes de mergulharmos no modelo em si.

Primeiro: o preço não mudou. O Opus 4.8 foi lançado no mesmo dia com o mesmo custo por token do 4.7 — US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de tokens de saída na velocidade padrão. Isso soa entediante até que você tenha vivido lançamentos de modelos suficientes para conhecer o padrão usual: "modelo mais inteligente, conta mais gorda." Desta vez não. A Anthropic também barateou o modo rápido. E há um ganho de eficiência mais silencioso escondido na documentação: high effort no 4.8 consome aproximadamente os mesmos tokens numa tarefa de programação que a antiga configuração xhigh no 4.7 — com pontuação mais alta. Você obtém mais raciocínio por token, não apenas mais raciocínio por dólar.

Segundo: os rate limits do Claude Code subiram. A Anthropic elevou os limites especificamente para acomodar o maior consumo de tokens nos novos níveis de esforço — um sinal forte sobre como este modelo foi projetado para ser utilizado. Eles esperam que você gaste mais tokens em tarefas difíceis. Eles construíram a margem. Se você acompanhou como a Anthropic dobrou os rate limits do Claude Code no início deste ano, esta é a mesma trajetória: mais poder computacional direcionado a quem realmente constrói com ele.

Então a manchete não é "Opus 4.8 é um pouco mais inteligente." É "Opus 4.8 é mais inteligente, custa o mesmo e te dá um novo controle para determinar o quanto ele pensa." Esse controle é todo o jogo. Chegaremos lá. Primeiro, vamos ao gráfico, porque você já o viu e tem perguntas.

Os números de benchmark — incluindo o único que ele perde

Aqui está a comparação que a Anthropic publicou, direto do anúncio. Reproduzo os números exatos porque as diferenças dizem mais que o título.

Olhe para o salto do SWE-Bench Pro: de 64,3% para 69,2%. Quase cinco pontos de ganho em programação agêntica num point release, enquanto o GPT-5.5 fica em 58,6% e o Gemini 3.1 Pro atrás com 54,2%. Isso não é erro de arredondamento. É a diferença entre um modelo que conclui uma mudança em múltiplos arquivos e um que trava.

Os números de raciocínio se movem na mesma direção. Humanity's Last Exam sem ferramentas sobe de 46,9% para 49,8%, e com ferramentas para 57,9% — ambos liderando com folga. Trabalho de conhecimento no GDPval-AA salta de 1753 para 1890, o que nessa escala é uma margem significativa sobre os 1769 do GPT-5.5 e está a quilômetros de distância dos 1314 do Gemini.

Agora a parte honesta. O Opus 4.8 não ganha em tudo.

Na programação agêntica em terminal — Terminal-Bench 2.1 — o GPT-5.5 ainda vence, 78,2% contra 74,6%. Essa é uma derrota real, não margem de erro, e eu estaria mentindo se dissesse o contrário. Se o seu fluxo de trabalho depende muito do terminal — longas cadeias de comandos shell, orquestração de CI, loops agênticos de bash puro — o GPT-5.5 e o Codex ainda têm vantagem aí. Rodei ambos lado a lado no mesmo repositório por alguns dias, e a diferença é visível: o Codex é simplesmente um pouco mais seguro quando toda a tarefa vive no terminal. Já escrevi antes sobre rodar Claude Code e Codex lado a lado no mesmo repo, e o 4.8 reduz essa lacuna de terminal em relação ao 4.7 (66,1%) — mas não a fecha.

Se você veio aqui esperando que "Opus 4.8 destrói tudo" — essa não é a verdade. A verdade é: ele lidera em seis de sete categorias, frequentemente por grande margem, e perde uma — programação em terminal — para o GPT-5.5. Guarde esse asterisco na cabeça. Ele será importante quando falarmos sobre qual modelo escolher em cada momento.

Mas aqui está o que o gráfico não pode te mostrar. Nenhum desses números significa nada até você entender a alavanca que os controla.

Níveis de esforço: A configuração que decide tudo

A funcionalidade destaque do Opus 4.8 não é um benchmark. É um controle deslizante.

No Claude Code, agora você pode configurar o nível de esforço do modelo em cinco etapas: low → medium → high (padrão) → max → ultra. Esta é a coisa mais importante para entender neste lançamento, porque é a diferença entre o modelo que resolveu brilhantemente minha refatoração e o modelo que a teria estragado.

Veja como os níveis se comportam na prática:

O modelo mental que funcionou para mim: nível de esforço é um orçamento de pensamento. Aumente e o modelo raciocina com mais intensidade, mantém mais contexto na memória de trabalho e persiste em tarefas que de outra forma abandonaria. Diminua e você obtém respostas rápidas e baratas que são perfeitas para uma consulta mas desmoronam diante de uma refatoração real.

Uma nota sobre nomenclatura, porque me confundiu e vai te confundir também. A própria documentação da Anthropic descreve os níveis subjacentes de raciocínio como low, high (padrão) e um nível superior "extra"/xhigh — e no Claude Code, o nível mais alto é exibido como ultracode, que combina raciocínio xhigh com orquestração automática de workflows. O modelo de cinco níveis (low / medium / high / max / ultra) é o modelo mental mais limpo para uso diário, e é assim que tratarei aqui, mas se você investigar no anúncio oficial e encontrar "xhigh" e "ultracode", é a mesma marcha superior com rótulo diferente. Não deixe o vocabulário te confundir — tudo é o mesmo controle.

Esse nível superior merece seu próprio parágrafo. Ultra (também conhecido como ultracode no Claude Code) é esforço máximo mais workflows dinâmicos, onde o modelo planeja o trabalho e então inicia sub-agentes paralelos para resolver problemas em larga escala de forma autônoma. Esta é a parte que genuinamente me surpreendeu: workflows dinâmicos podem orquestrar até 1.000 sub-agentes paralelos em uma única sessão (esse é o limite rígido que a Anthropic estabeleceu), e no 4.8 esses agentes funcionam por mais tempo antes de esgotar. Pense em "reescreva este módulo, migre os testes, atualize a documentação e verifique o build" como uma única instrução, com o modelo escrevendo seu próprio plano de orquestração e sequenciando as subtarefas em vez de esperar que você alimente cada uma. Depois ele verifica seus próprios resultados antes de reportar. É o sucessor espiritual do trabalho orientado a objetivos que cobri quando os comandos /for e /goal mudaram meu fluxo de trabalho com Claude Code — exceto que agora a orquestração é tarefa do modelo, não um comando que você acopla. Bom saber: workflows dinâmicos foram lançados como research preview, então espere alguma aspereza neste nível.

Aqui está a armadilha, e eu caí nela no primeiro dia. O padrão é high, e o padrão está errado para metade das suas tarefas. Muito baixo, e o modelo termina prematuramente ou raciocina fracamente — exatamente a preguiça do 4.7 da qual todos reclamavam, exceto que agora é uma configuração que você escolheu, não um defeito que herdou. Muito alto, e o modelo sobreanalisa uma consulta de configuração de uma linha, queima 8.000 tokens e leva 40 segundos para te dizer algo que um grep teria respondido instantaneamente.

A habilidade não é escolher o nível mais alto. A habilidade é ajustar o esforço à complexidade da tarefa. Esse é todo o jogo. Já vamos ficar táticos.

Como o Opus 4.8 se comporta diferente — além do controle deslizante

Os níveis de esforço ganham as manchetes, mas o comportamento subjacente do modelo mudou de formas que importam igualmente no uso diário. Após uma semana, quatro mudanças se destacam.

Ele raciocina antes de recorrer a ferramentas. Este é o grande. O Opus 4.7 tinha o gatilho fácil — disparava uma chamada de ferramenta ou iniciava um sub-agente antes de ter realmente pensado se precisava. O 4.8 tenta resolver o problema internamente primeiro e só invoca ferramentas ou sub-agentes quando o raciocínio sozinho não basta. Na prática isso significa menos chamadas inúteis a ferramentas, menos inícios de sub-agentes pela metade, e um modelo que parece estar pensando em vez de se debatendo sem rumo.

Ele calibra o comprimento da resposta à tarefa. Faça ao 4.8 uma pergunta factual rápida e você recebe uma resposta curta. Peça que analise uma decisão de arquitetura e você recebe a profundidade que a pergunta merece. O 4.7 tinha um único botão de volume, fixado em "verboso." O 4.8 lê o ambiente.

É mais honesto sobre seu próprio progresso. A Anthropic ajustou isso explicitamente, e os números confirmam — documentaram uma redução de aproximadamente quatro vezes em falhas de código não reportadas, o que significa que o 4.8 é muito menos propenso a despachar silenciosamente um bug e dar o trabalho por encerrado. Menos falsos avisos de "pronto!". Menos conclusões fantasma onde o modelo jura que os testes passam e não passam. A história da refatoração do início deste post é o exemplo canônico — ele me disse o que não havia tocado e por quê. Essa é a maior melhoria de confiança neste lançamento, e é o tipo de coisa que nenhum título de benchmark captura.

O tom ficou mais caloroso. O Opus 4.7 tinha um toque do que a comunidade caridosamente chamava de "sass" — uma borda levemente rígida, ocasionalmente contrária, mais um excesso de cautela de segurança que o fazia recusar ou hesitar em pedidos perfeitamente razoáveis. O 4.8 é mais colaborativo. Mais caloroso. Ele questiona quando deve, mas não dá sermão. Se você se afastou por causa da atitude do 4.7, isso sozinho pode ser suficiente para te trazer de volta.

Há uma mudança mais silenciosa por baixo de todas as quatro, e é aquela em que a Anthropic mais se apoiou: orientação a objetivos agora é um traço central, não um remendo. Com o 4.7, fazer o modelo trabalhar em direção a um resultado — em vez de apenas satisfazer o texto literal da sua última mensagem — exigia prompting deliberado e os comandos certos. O 4.8 mantém o objetivo ao longo de uma tarefa longa e se orienta para ele. Quando encontra uma bifurcação ambígua, faz uma pergunta mais precisa em vez de adivinhar ou travar. Numa execução autônoma de 40 minutos, essa é a diferença entre voltar para trabalho concluído e voltar para uma desculpa educada. Também faz com que o 4.8 faça menos perguntas que o 4.7 — mas as que faz são as que realmente desbloqueiam o trabalho.

Empilhe essas quatro com o controle deslizante de esforço e você obtém um modelo que não apenas pontua mais alto — ele se sente fundamentalmente mais como um colega de equipe e menos como uma ferramenta com a qual você precisa lutar. O que nos traz à parte pela qual você realmente veio: como usá-lo.

Como estou realmente configurando o Opus 4.8 (passo a passo)

Benchmarks são teoria. Aqui está a configuração prática na qual cheguei após uma semana de tentativa e erro. Copie e depois ajuste ao seu próprio trabalho.

Passo 1: Pare de aceitar o nível de esforço padrão

A primeira coisa que fiz de errado foi deixar tudo em high e me perguntar por que tarefas simples pareciam lentas e caras. Não faça isso. Antes de começar uma tarefa, faça uma pergunta: quão difícil isso realmente é?

• Procurar algo, renomear uma variável, um rápido "onde X está definido?" → low. Ele responde em segundos por uma fração dos tokens.
• Escrever uma função focada, uma mudança em um arquivo, um bugfix normal → medium.
• A maioria do trabalho real com features, mudanças em múltiplos arquivos, qualquer coisa onde você gostaria que um colega realmente pensasse → high (o padrão merece seu lugar aqui).
• Refatorações complicadas, decisões de arquitetura, debugging de algo genuinamente sutil → max.
• "Migre todo este módulo e verifique" — trabalho em escala onde você quer que o modelo planeje e sequencie subtarefas → ultra com workflows dinâmicos.

Dica pro: Tenho um post-it no meu monitor que diz apenas: "ajuste o dial à dificuldade." É bobo, e me economizou mais tokens do que qualquer prompt inteligente.

Passo 2: Diga ao modelo o que FAZER, não o que NÃO fazer

Este não é um conselho novo, mas importa mais com o 4.8 porque o modelo é muito melhor em seguir instruções positivas. Em vez de "não quebre os testes existentes," escreva "mantenha cada teste existente verde e adicione novos para qualquer comportamento que você alterar." O enquadramento positivo dá ao modelo um alvo para mirar em vez de um campo minado para navegar. A diferença na qualidade do output é real e consistente.

Passo 3: Dê o porquê por trás das suas instruções

A mudança de prompting com maior alavancagem que fiz para o 4.8: explique o raciocínio. Não diga apenas "use o padrão repository aqui." Diga "use o padrão repository aqui porque no próximo sprint vamos trocar a fonte de dados de MySQL para uma API externa, e quero que o código chamador não seja tocado quando fizermos isso."

Quando o 4.8 entende o porquê, tanto a conformidade quanto o julgamento saltam. Ele toma melhores decisões nas lacunas que suas instruções não cobriram, porque raciocina em direção ao seu objetivo real em vez de fazer correspondência de padrões com suas palavras literais. Isso combina perfeitamente com a mudança de comportamento "raciocina antes de agir" — dê-lhe bom material de raciocínio e ele raciocina bem.

Passo 4: Vigie seus tokens, especialmente em max e ultra

Maior esforço significa mais tokens. Esse é o acordo. Os rate limits ampliados te dão margem, mas margem não é infinita. Mantenha um rastreador de tokens ativo para que você possa ver quanto max e ultra realmente te custam em tarefas reais. Na primeira vez que rodei uma migração completa com workflow dinâmico em ultra, observei o contador e recalibrei imediatamente — parte daquele trabalho não precisava de ultra, precisava de max com um prompt mais enxuto. Se você leva custos a sério, meus truques de gestão de tokens no Claude Code continuam valendo, e valem mais agora que você tem um dial que pode silenciosamente queimar seu orçamento.

Passo 5: Teste, não assuma que o upgrade ajuda

Aqui está a verdade desconfortável que ninguém coloca em posts de dia de lançamento: um modelo mais novo não garante melhores resultados para o seu caso de uso. O Opus 4.8 é claramente um passo à frente no conjunto. Mas tenho uma tarefa específica de formatação de conteúdo onde o output do 4.7 era realmente mais limpo para meu pipeline, e mantive aquele prompt ajustado da maneira antiga até testá-lo adequadamente.

Rode seus workflows reais. Compare. Ajuste. O modelo é um ponto de partida, não uma resposta definitiva.

Se você prefere que alguém configure e ajuste todo esse workflow de níveis de esforço para o stack da sua equipe em vez de aprender na raça, esse é o tipo de trabalho que eu assumo — você pode ver o que construí em fiverr.com/s/EgxYmWD.

A verdade honesta: a maioria dos "falhas do modelo" são culpa sua

Deixe-me dizer o que vai irritar algumas pessoas. Depois de uma semana com o Opus 4.8 e anos usando esses modelos diariamente, estou convencido de que a maioria das reclamações de "o modelo é burro / preguiçoso / quebrou meu código" não são falhas do modelo. São falhas de prompting e configuração do lado do usuário.

Vi acontecer em tempo real durante a era 4.7. As pessoas deixavam o modelo em configurações agressivas padrão, davam instruções vagas de uma linha sem justificativa, sem contexto, sem objetivo claro, e depois postavam capturas de tela reclamando que o modelo "desistiu." O modelo não desistiu. Ele fez exatamente o que uma instrução subespecificada no nível de esforço errado produz.

O Opus 4.8 torna isso ainda mais claro, porque agora o nível de esforço está nas suas mãos. Se você roda uma refatoração difícil em esforço baixo, o modelo terminará prematuramente — e isso não é preguiça, é você dizendo para ele pensar superficialmente. Se você roda uma consulta trivial em ultra, ele sobreanalisará e queimará tokens — e isso não é inchaço, é você girando o dial além do que a tarefa precisa.

Não isento completamente a Anthropic. O lançamento inicial teve bugs — algumas pessoas tiveram comportamento instável nas primeiras 48 horas, e eu mesmo peguei um loop estranho de sub-agentes antes que estabilizasse. O sentimento da comunidade é misto-mas-positivo, o que é honesto: as pessoas amam a programação e o estilo de colaboração mais caloroso, algumas encontraram arestas no lançamento. A Anthropic itera com base em feedback e logs de usuários, então os pontos ásperos tendem a se suavizar em dias. Esse tem sido o padrão ao longo do 4.6 e 4.7.

Mas a lição duradoura permanece: o modelo é mais capaz do que seus padrões permitem que ele seja. Corrija os padrões antes de culpar o modelo. Essa única mudança de mentalidade fará mais pela sua produção do que esperar pelo 4.9.

O que estou realmente vendo no uso diário

Não vou inventar números precisos que não posso comprovar — esse é um jeito garantido de perder sua confiança. Mas posso te contar os padrões consistentes de uma semana de trabalho real em repos de clientes, meu pipeline de conteúdo e um projeto paralelo.

Em tarefas de programação agêntica, a diferença entre 4.7 e 4.8 é mais óbvia em trabalhos longos. O tipo de refatoração em múltiplos arquivos que o 4.7 abandonaria a dois terços do caminho, o 4.8 leva até o fim — e isso se alinha exatamente com o salto do SWE-Bench Pro de 64,3% para 69,2%. A autonomia sustentada é a funcionalidade destaque na prática. Ele simplesmente continua onde o 4.7 parava.

Eficiência de tokens é o que estou monitorando mais de perto. A Anthropic alega melhoria, e o comportamento de "raciocina antes de recorrer a ferramentas" deveria significar menos chamadas inúteis. No meu uso isso se confirma de modo geral — menos chamadas lixo a ferramentas em esforço médio e alto. Mas max e ultra são genuinamente caros, e isso não é regressão, é o design. Ganhos de eficiência na faixa baixa a média, gastos deliberados na faixa alta. Verifique nas suas próprias cargas de trabalho antes de confiar em qualquer afirmação geral de "é mais barato", incluindo a minha.

A melhoria de honestidade é a que silenciosamente mudou como eu trabalho. Porque o 4.8 é mais confiável ao sinalizar o que não terminou ou sobre o que não tinha certeza, gasto menos tempo verificando conclusões fantasma. Essa é uma economia de tempo real que não aparecerá em nenhum gráfico — e ao longo de uma semana de uso diário, soma-se até o modelo parecer confiável de um jeito que o 4.7 nunca conseguiu totalmente. Para o panorama mais amplo de como os padrões mudaram ao longo desses lançamentos, minha análise anterior do Claude Opus 4.7 ainda estabelece a linha de base sobre a qual o 4.8 constrói.

A expectativa a definir: isto é um passo à frente genuíno, mas o upgrade que você sente é proporcional a quão bem você o conduz. Deixe no piloto automático e você terá um 4.7 levemente melhor. Ajuste os níveis de esforço às suas tarefas e você terá um modelo que conclui trabalhos que o anterior não conseguia.

Você deveria trocar? Minha resposta direta

Se você já está no Opus 4.7 no Claude Code: sim, troque agora. Mesmo preço, melhorias reais, e o controle deslizante de esforço sozinho já vale a mudança. Não há razão para ficar no 4.7 exceto inércia.

Se você vive no terminal — cadeias pesadas de bash, orquestração de CI, loops agênticos de shell puro: saiba que o GPT-5.5 ainda vence na programação em terminal com 78,2% contra 74,6%. Para esse trabalho específico, mantenha o Codex na sua caixa de ferramentas. Para todo o resto, o Opus 4.8 é a escolha mais forte por larga margem. Usar ambos não é se proteger — é simplesmente usar a ferramenta certa para o trabalho certo, a mesma conclusão que tirei quando comparei GPT-5.5 e Opus 4.7 com código idêntico.

Se você é novo em tudo isso: comece no Opus 4.8, deixe em high e só comece a mexer no controle deslizante quando sentir onde high exagera e onde fica aquém. O dial é poderoso, mas você precisa desenvolver intuição para ele.

Perguntas frequentes

O que são níveis de esforço no Claude Opus 4.8?

Níveis de esforço são um orçamento de pensamento controlável no Claude Code com cinco configurações: low, medium, high (o padrão), max e ultra. Maior esforço significa raciocínio mais profundo, mais tokens e respostas mais lentas; menor esforço significa saída mais rápida, mais barata e mais superficial. Ajuste o nível à complexidade da sua tarefa. Consulte "Níveis de esforço: A configuração que decide tudo" acima para o detalhamento completo.

O Claude Opus 4.8 é melhor que o GPT-5.5?

O Opus 4.8 lidera em seis de sete benchmarks publicados, incluindo programação agêntica (69,2% vs. 58,6% no SWE-Bench Pro) e raciocínio. O GPT-5.5 ainda vence na programação agêntica em terminal, 78,2% contra 74,6%. Para a maioria do trabalho de programação e raciocínio, o Opus 4.8 é mais forte; para workflows intensivos de terminal, o GPT-5.5 mantém vantagem.

O Claude Opus 4.8 custa mais que o Opus 4.7?

Não. O Opus 4.8 foi lançado em 28 de maio de 2026 ao mesmo preço por token do Opus 4.7. A Anthropic também elevou os rate limits do Claude Code para acomodar o maior uso de tokens nos novos níveis de esforço. Note que os níveis max e ultra consomem significativamente mais tokens por tarefa.

O que são workflows dinâmicos no Claude Code?

Workflows dinâmicos são um recurso do Claude Code, ativado no nível de esforço ultra, onde o Opus 4.8 planeja e orquestra múltiplos passos e subtarefas para resolver problemas em larga escala de forma autônoma. Em vez de você sequenciar cada passo, o modelo decompõe o trabalho e o resolve por conta própria.

Devo sempre usar o nível de esforço mais alto?

Não — esse é o erro mais comum. Max e ultra sobreanalisam tarefas simples e queimam tokens desnecessariamente, enquanto esforço baixo causa término prematuro em trabalho difícil. A habilidade é ajustar o esforço à dificuldade da tarefa: low para consultas, high para trabalho real de features, max para refatorações complicadas, ultra para trabalhos autônomos em larga escala.

A refatoração que me convenceu

Lembra daquele monstro de 600 linhas em Laravel do começo deste post? Ele está em produção há seis dias. Três classes limpas, cobertura completa de testes, e a camada de cache que o Opus 4.8 deliberadamente se recusou a tocar — porque me disse que não tinha certeza — revelou ter uma sutileza que eu mesmo havia esquecido. Se o modelo a tivesse reescrito "com confiança" como o 4.7 faria, teria deployado um bug.

Essa é a verdadeira melhoria. Não os cinco pontos no SWE-Bench Pro. Não o tom mais caloroso. É um modelo que conhece o limite da sua própria competência e te diz onde ele está. Combine essa honestidade com um controle deslizante de esforço que você realmente sabe operar, e você tem o primeiro Claude que parece menos uma ferramenta que você supervisiona e mais um colega em quem confia.

Então aqui está sua tarefa para as próximas 24 horas: abra o Claude Code, pegue a tarefa mais difícil do seu dia, configure o nível de esforço em max e dê o porquê por trás do que você está pedindo. Depois observe o que acontece quando você para de lutar contra os padrões e começa a pilotar o modelo com intenção.

Vamos trabalhar juntos

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

• Fiverr (desenvolvimento sob medida e integrações): 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