Iniciantes

A mensagem "Claude usage limit reached" do Claude Code não é um erro, e sim como funcionam os limites de uso da assinatura Pro/Max. Explicamos a estrutura em duas camadas (janela rolante de 5 horas + janela semanal, com um teto separado para o Opus no Max), o que mais consome a cota e o que fazer ao bater no teto: baixar para o Sonnet com /model, enxugar o contexto com /compact e, quando não dá para esperar, migrar para a API pay-as-you-go. Inclui como ver quanto resta com /usage e um checklist de prevenção.

O erro "Prompt is too long" no Claude Code ou na API significa que sua entrada (histórico + arquivos + definições de ferramentas) supera a janela de contexto do modelo, e não que você esgotou sua cota. Explicamos o que preenche a janela, os tamanhos 200K e 1M, como resolver com /compact, /clear e subagents, e como distinguir de erros que se confundem.

Quando um servidor MCP não conecta no Claude Code, o caminho mais curto é classificar pelo status do /mcp em três famílias: failed (falha ao iniciar o local), needs authentication (OAuth remoto) e pending approval (aprovação do projeto). Explicamos como ler o status, correções causa por causa, a armadilha do npx no Windows e o fluxo de diagnóstico com claude --debug mcp.

Rodando sessões longas no Claude Code, às vezes "court" (ou "call") e tags <invoke> cruas vazam como texto e o comando nunca é executado. Não é o seu ambiente: é uma falha do lado do modelo (Opus 4.8 / 4.7) que corrompe o token de controle da chamada de ferramenta. O harness a rejeita em modo fail-closed, então não há risco de comando errado — mas o bloco quebrado "encadeia" no histórico. Veja as causas, os equívocos comuns, as correções para usuário e desenvolvedor, e por que sair para uma sessão nova (/clear) é a melhor jogada.

Um dia sua conta do ChatGPT ou do Claude simplesmente para de funcionar: em 2026, relatos de suspensões de conta (banimentos) e advertências estão aumentando, e o assustador é que você pode ser banido por quebrar os termos sem querer, mesmo sem nenhuma má intenção. Este artigo organiza o que saber para não perder sua conta na OpenAI (ChatGPT, Codex) e na Anthropic (Claude, Claude Code), com base nas políticas de uso publicadas e em relatos (não um guia para escapar da detecção, mas para manter-se em conformidade). Cinco gatilhos comuns a ambas: conteúdo proibido / jailbreaks (geração ilegal ou prejudicial, tentar burlar filtros de segurança via prompts; violações graves podem ser um banimento permanente imediato), automação / scraping não autorizados (bots, scripts, acesso enganoso em massa como spam/phishing), compartilhar ou revender contas/chaves de API, padrões de acesso suspeitos (mudanças frequentes de IP/país, VPN intensa, troca de dispositivos interpretadas como logins anormais) e pagamento incompatível/fraude (diferenças geográficas, métodos de pagamento suspeitos). A maior cilada de 2026: usar tokens OAuth de plano pessoal (Free/Pro/Max) do Claude em qualquer produto que não seja o app oficial, incluindo harnesses como o Agent SDK, é uma violação dos ToS para Consumidores que causou uma grande onda de banimentos; o jeito certo é executar apps/agentes via API (pague conforme o uso) e tratar os planos pessoais como conversa no app oficial. Específicos da OpenAI: contornar segurança/restrições de acesso, automação/scraping, reutilização indevida de chaves de API, usos ilegais. Específicos da Anthropic: uso indevido de tokens OAuth de plano pessoal, acesso de terceiros não oficial, cláusulas antidestilação/de modelos concorrentes, jailbreaks. Um checklist de prevenção com 7 pontos (leia a política, combine plano e propósito, não coloque tokens pessoais em ferramentas de terceiros, sem jailbreaks/conteúdo proibido, não compartilhe nem revenda, pagamento compatível com a região e acesso estável, aja diante de advertências imediatamente). Advertências são uma chance de corrigir e a maioria pode continuar; violações leves ou acidentais podem ser recorríveis, mas as graves são permanentes e difíceis de recuperar. O plano certo, para o propósito certo, com honestidade. Sempre confirme os termos oficiais atuais de cada empresa.

Retreinar uma IA gigante do zero é caro demais, mas você quer ajustá-la só para você; o LoRA (Low-Rank Adaptation) realiza esse desejo congelando o modelo original e treinando apenas uma pequena peça adicional (um adaptador), cortando os parâmetros treináveis em cerca de 90%. O LoRA torna o fine-tuning drasticamente mais barato e rápido, e é enormemente popular na geração de imagens, como no Stable Diffusion, como um pequeno arquivo que adiciona um personagem ou estilo. Este artigo explica com uma analogia de remendo. O LoRA é o carro-chefe do fine-tuning eficiente em parâmetros (PEFT): deixar os enormes pesos originais congelados, inserir uma pequena matriz adicional em cada camada e treinar apenas isso (W = W0 + BA, onde W0 fica congelado e BA é a pequena parte adicionada). Ele se baseia na descoberta de que adaptar uma IA não exige grandes mudanças (um rank baixo basta). Benefícios: cerca de 90% menos parâmetros treináveis (segundo relatos, 10.000x menos na escala do GPT-3), menos memória de GPU (cerca de 3x menos), treinamento mais rápido e barato, sem latência de inferência depois que o adaptador é mesclado, e menor risco de overfitting. Sua maior força são os adaptadores intercambiáveis: mantenha uma base comum e troque pequenos arquivos LoRA (de poucos MB) por caso de uso (suporte, tom da empresa, um personagem específico) instantaneamente. Muita gente encontra o LoRA pela primeira vez na geração de imagens, onde LoRAs do Stable Diffusion que aprenderam um personagem, estilo ou tema são amplamente compartilhados. O QLoRA combina a quantização, treinando o LoRA sobre uma base 4-bit para ~4x menos memória que o LoRA padrão, permitindo o fine-tuning de modelos enormes em uma GPU de consumo (às vezes CPU) com perda mínima de precisão. Diferentemente do fine-tuning completo (treinar todos os pesos), o LoRA difere nos pesos treinados, no custo, no resultado e no melhor uso; para a maior parte do trabalho, o LoRA basta. Mantenha a base, tempere pouco. Os números são citados de materiais públicos, como orientação.

Um enorme modelo de 70B rodando em um único PC gamer caseiro, em vez de um rack de GPUs de data center, é possível graças à quantização, que reduz a precisão numérica dos pesos do modelo para encolher drasticamente tamanho e memória. Enquanto a destilação transfere conhecimento para um modelo separado e menor, a quantização deixa o mesmo modelo mais leve. Este artigo explica isso com uma analogia de compressão de fotos. A quantização substitui pesos armazenados como decimais FP16/FP32 por inteiros INT8 (8 bits) ou INT4 (4 bits), cortando bytes por peso (FP32=4, INT8=1, INT4=0,5); como comprimir uma foto RAW para JPEG, você sacrifica um pouco de precisão por uma grande redução, e a surpresa é o quão pouco abre mão. Em memória, 4-bit usa cerca de um quarto do FP16: um modelo de 70B cai de ~140GB para ~35GB, e um de 8B em 4-bit fica em ~4.5-5GB, cabendo em uma GPU intermediária de 8GB de VRAM para uso local (a democratização dos LLMs). Em precisão, INT8 é praticamente sem perdas e INT4 degrada abaixo de 4% em perguntas e respostas gerais e senso comum, mas a perda é mais perceptível em matemática, geração de código e raciocínio difícil (aparece como um pequeno aumento na perplexidade), então escolha a precisão em bits pela tarefa. Principais métodos: GPTQ (pioneiro do 4-bit preciso), AWQ (protege os ~1% pesos mais importantes, frequentemente 1-2% mais preciso e rápido), GGUF (formato llama.cpp/Ollama, Q2_K-Q8_0, híbrido CPU+GPU, para uso local) e QLoRA (base de 4-bit mais LoRA para fine-tuning em GPU de consumidor). Difere da destilação (mudar para um modelo separado menor) e do fine-tuning (adicionar conhecimento de tarefa), e as três costumam ser combinadas (quantizar um modelo destilado; fazer fine-tuning sobre uma base quantizada). Para começar, rode um modelo GGUF com o Ollama em um comando, escolha Q4/Q8 pela VRAM e evite INT4 para código ou matemática exata. A maioria dos grandes modelos já vem quantizada, então basta baixar e usar. Mantenha a inteligência, tire apenas o peso. Os números são citados de materiais públicos, indicativos.

Uma IA enorme e de alto desempenho é inteligente, mas pesada e cara; a destilação de modelos (destilação de conhecimento) resolve isso transferindo o conhecimento de um grande modelo professor para um pequeno modelo aluno, mantendo mais de 95% do desempenho do professor com um décimo do tamanho e da velocidade. Este artigo explica o tema com uma analogia professor-aluno. A chave são os soft labels: o treinamento comum só ensina "a resposta é gato" (hard label), enquanto a destilação passa toda a distribuição de probabilidade do professor, como "90% gato, 8% cachorro, 2% raposa", cujo grau de hesitação carrega informações ricas; um parâmetro temperature suaviza as probabilidades para revelar relações sutis (exemplo real: GPT-4o mini destilado a partir do GPT-4o). Benefícios: rápido e barato, ~10x mais compacto mantendo mais de 95% do desempenho, roda na edge e é forte para especialização. Duas abordagens: white-box (acesso total a pesos e representações internas, transferência mais profunda; para seus modelos ou modelos OSS) e black-box (só as saídas/respostas da API visíveis; usar a API de outra empresa como professor pode violar os termos). Difere da quantização (comprimir a precisão dos pesos do mesmo modelo) e do fine-tuning (continuar treinando um modelo existente para uma tarefa) — a destilação move o conhecimento para um modelo pequeno separado, e as três são combináveis. A realidade jurídica/ToS foi um grande tema em 2026: a técnica é legítima, mas OpenAI, Anthropic, Mistral e xAI incluem cláusulas de destilação anticompetitiva que proíbem usar saídas para criar modelos concorrentes, então destilar um concorrente a partir de uma API restrita pode violar os termos. A disputa OpenAI v. DeepSeek (a OpenAI alegou que contas ligadas à DeepSeek burlaram restrições para obter saídas para destilação, enquanto os termos da DeepSeek supostamente permitem destilar suas saídas) mostra que a avaliação depende de quais termos de API se aplicam, e o Claude Fable 5/Mythos 5 supostamente restringe respostas sobre trabalho sinalizado como destilação. Dicas: use seus modelos ou modelos OSS licenciados como professor, verifique as cláusulas antidestilação antes de usar uma API comercial e avalie se o uso configura desenvolvimento de um modelo concorrente. Inteligência do modelo grande, operação do pequeno — mas quem você escolhe como professor muda o resultado técnica e juridicamente. Os números são citados de materiais públicos, em caráter orientativo.

Em "Como construir um sistema multiagente" dissemos para instrumentar cada handoff antes de adicionar agentes; a tecnologia que sustenta essa instrumentação em produção é a observabilidade de IA. Ela torna visível o que LLMs e agentes realmente fazem em produção (qual modelo com qual prompt, quais ferramentas e buscas, o que foi retornado, quanto tempo e quanto custou) para que você possa rastrear até a causa. A diferença decisiva em relação ao monitoramento comum: a IA pode retornar 200 OK em 50ms e ainda alucinar com confiança, então a maioria das falhas de IA são falhas de qualidade (alucinação, recuperação fraca, respostas inseguras, tarefas incompletas, uso ruim de ferramentas, regressões após mudar o prompt), não falhas de infraestrutura. A observabilidade se apoia em três pilares: traces (uma requisição como árvore de spans mostrando chamadas de LLM, ferramentas, recuperação, cadeias de raciocínio; a estrela da observação de IA), métricas (latência, custo, tokens, taxa de erro, throughput) e logs (detalhe por evento). O padrão da indústria, as convenções GenAI do OpenTelemetry, captura prompts, respostas, uso de tokens e chamadas de ferramentas/agentes em um esquema neutro alimentável no Datadog/Grafana. A distinção mais confundida é observabilidade vs avaliação (evals): a observabilidade mostra o que aconteceu (fácil de medir, mas não diz se a resposta está correta), enquanto as evals medem se a resposta é boa (precisão, groundedness, segurança) e exigem avaliação explícita. Como custo e latência são fáceis de medir mas a qualidade da resposta não, as ferramentas de 2026 combinam exibição de traces com pontuação de saídas e alertas de degradação. As métricas se dividem em operacionais (custo, latência, tokens, taxa de erro) e de qualidade (alucinação, groundedness/fidelidade que é a mais crítica para RAG, segurança, conclusão da tarefa), com detecção de alucinação via LLM-as-a-judge, similaridade semântica e scores de groundedness. Principais ferramentas: LangSmith (LangChain), Langfuse (open-source self-host), Arize Phoenix (depuração de RAG), MLflow (ciclo de vida), AgentOps (agentes) e OpenTelemetry (o padrão). Comece capturando traces (compatível com OpenTelemetry), visualize métricas operacionais e depois conecte as evals antes de subir para produção. Para sistemas multiagente a observação é essencial, pois as falhas se escondem em cadeias de múltiplos passos visíveis apenas em um trace da sessão completa. Observar mais avaliar é o que torna a IA de nível de produção. Figuras e características são citadas de materiais públicos, direcionais.

Depois de assimilar o conceito em "O que é um sistema multi-agente?", esta é a continuação prática. Usando o padrão supervisor, o padrão de fato de 2026, ela guia iniciantes por uma construção em 5 passos. O princípio-chave: construa primeiro com um único agente e adicione mais de forma mínima só após bater num limite (~80% dos casos de uso ficam bem com um; usar multi para trabalho linear simples infla o custo 3-10x e, segundo pesquisa do Google, reduz a precisão em −39-70% em tarefas sequenciais). Três sinais para ir a multi: separação de especialidades, paralelismo, separação de decisão. O padrão supervisor (o supervisor recebe a tarefa global, decompõe-a, delega a workers especialistas e agrega resultados) é onde os subagentes do Claude Code, o LangGraph Supervisor e os handoffs do OpenAI Agents SDK convergiram, por ter o suporte mais amplo de frameworks, um modo de falha conhecido (delegação excessiva, limitada por um teto de iterações) e ser fácil de auditar. Os 5 passos: 1) decompor a tarefa com clareza desde o início; 2) definir workers com um papel + ferramentas + formato de saída (máx. 3-5); 3) projetar o supervisor, listando explicitamente os nomes chamáveis (limite rígido) e gastando o máximo de tempo aqui; 4) decidir handoff e compartilhamento de contexto, passando só o necessário (o padrão é A2A); 5) instrumentar cada handoff antes de adicionar agentes, limitar iterações/tokens/custo e configurar evals e guardrails. O pseudocódigo independente de framework mostra as definições de workers, um supervisor com limite rígido e um loop de execução com teto de iterações. Armadilhas comuns e soluções: delegação excessiva (limite + restringir workers chamáveis), inchaço de tokens (compartilhar só o necessário + cache), instabilidade (manter 3-5 + saída fixa), queda de precisão em sequencial (voltar ao único) e ponto de falha desconhecido (observabilidade). A lição compartilhada: prompts, design de ferramentas e o harness de eval decidem o sucesso mais do que o framework. Construa pequeno, meça e adicione só quando compensa. Os dados são citados de materiais públicos e pesquisa, dependentes de condições.

"Dividir entre vários agentes um trabalho complexo que um único agente de IA não dá conta" é a ideia por trás dos sistemas multi-agente. Este guia para iniciantes apresenta a mecânica, os principais padrões e os principais frameworks e, o mais importante, a regra de decisão real sobre quando usar vários agentes e quando um basta, sem exageros. Um sistema multi-agente faz vários agentes de IA especializados por papel trabalharem juntos em uma grande tarefa; em contraste com um único agente que faz tudo (suficiente para ~80% dos casos, barato e fácil de depurar), ele divide o trabalho por especialidade para execução paralela e verificação cruzada, a um custo de coordenação e uso de tokens maiores. Os quatro padrões de orquestração dominantes são: orchestrator-worker (um líder decompõe, despacha workers em paralelo e sintetiza; o mais usado, com trilha de auditoria), repasse sequencial (passa o contexto ao próximo agente), conversa em grupo (agentes debatem em um thread com um selecionador escolhendo quem fala; bom para verificação cruzada) e máquina de estados em grafo (agentes como nós, transições como arestas, estado explícito; forte para ramificações e checkpoints). Os frameworks se consolidaram em 2026: LangGraph (maior presença em produção), CrewAI (menor curva de aprendizado, prototipagem), AutoGen/AG2 (debate e verificação, pesquisa) e OpenAI Swarm (handoffs leves). Mas não é panaceia: tarefas complexas e multidomínio têm até +23% em benchmarks de raciocínio, porém em tarefas sequenciais lineares uma pesquisa da Google constatou −39-70% vs um único agente, o mesmo poder de computação dado a um agente costuma empatar ou vencer, e 7 de 10 implantações teriam aumentado o custo sem ROI a ~15x de consumo de tokens (ROI médio 2.5-3.5x, quartil superior 4-6x quando bem direcionado). O caminho recomendado: construa único primeiro, identifique um teto concreto (papéis confusos, trabalho paralelizável), depois adicione uma equipe mínima de 2-3 agentes no padrão do líder com teto de custo e logging, e meça se o ganho de precisão justifica o aumento. A2A (protocolo de comunicação) e MCP (conexão de ferramentas) são tecnologia de base que sustenta o multi-agente. Único para 80%, multi só para as partes difíceis. Os números são citados de pesquisas e estudos e dependem das condições, sendo indicativos.

Agora que os agentes de IA se tornaram comuns, o próximo desafio é como fazê-los colaborar entre si. Se o MCP conecta um agente às suas ferramentas, o A2A (Agent2Agent) conecta um agente a outro agente — um padrão aberto para que IAs construídas com fornecedores e frameworks diferentes se descubram, se comuniquem e cooperem por meio de uma convenção comum. O Google o lançou em abril de 2025, doou-o à Linux Foundation em junho daquele ano, e ele chegou à v1.0 em 2026. Este guia para iniciantes cobre o que é o A2A (a analogia da etiqueta de uma parceria de negócios), por que é necessário (agentes especializados revezam o trabalho — um agente de planejamento, um de reserva de hotel, um de pagamento), como se diferencia do MCP (o MCP é vertical, agente ↔ ferramentas; o A2A é horizontal, agente ↔ agente; empilhar os dois é a configuração padrão de duas camadas), como funciona (um Agent Card — um JSON "cartão de visita" em /.well-known/agent-card.json — é usado para descobrir capacidades, depois uma Task carrega a solicitação por estados como working, input-required e completed, e um Artifact retorna o resultado, tudo sobre HTTP, Server-Sent Events e JSON-RPC 2.0, com os agentes mantendo seus detalhes internos ocultos), e qual é a situação atual e a implementação (em abril de 2026, 150+ organizações em produção, 22.000+ estrelas no GitHub, SDKs em cinco linguagens — Python, JavaScript, Java, Go, .NET — com Microsoft, Salesforce, SAP e ServiceNow envolvidos). O mnemônico: conectar a ferramentas = MCP, conectar a pares = A2A.