Ambiente de Desenvolvimento e Infraestrutura para IA

O Projects do Claude Code foi reconstruído. Até agora um projeto era uma pasta que guardava conversas e material de referência; o novo Projects é uma única conversa. Você escreve o que precisa, o Claude divide aquilo em threads, as threads rodam em paralelo na nuvem e cada uma abre um pull request e volta com um relato quando termina. Fechar o notebook não as interrompe. Antes de mergulhar, porém, vale conferir três coisas: as contas que podem usar ainda são poucas (um beta público de Pro e Max, que chega primeiro às contas sem projetos existentes), o github.com e o Claude GitHub App são exigências na prática, e a velocidade com que isso devora o seu limite de uso não tem nada a ver com a de uma sessão única. Este artigo percorre como saber se a liberação já chegou até você, com o que uma thread começa (incluindo a armadilha em que regras de permissão e hooks deixam de valer assim que um projeto tem mais de um repositório), de onde vem o custo em tokens, inclusive o padrão de Opus em esforço high, e como escolher entre as cinco formas de trabalhar em paralelo: subagents, agent view, Agent Teams, dynamic workflows e Projects, tudo a partir da documentação e do blog oficiais.

Você quer deixar só o planejamento com um modelo mais inteligente e passar a implementação para um modelo mais rápido e mais barato. O opusplan do Claude Code é uma indicação de modelo que faz isso automaticamente. Ele roda no Opus durante o modo de planejamento e no Sonnet no resto do tempo, e pode ser usado com /model opusplan ou com o model do settings.json. Mas ele não aparece na lista do /model e, como o modelo troca toda vez que você entra ou sai do modo de planejamento, a cada troca a conversa inteira é relida sem cache. Com base na documentação oficial, no histórico de mudanças e nas issues do GitHub em 15 de setembro de 2026, este artigo organiza como configurar (incluindo fixar versões e o contexto de 1M), o fluxo do modo de planejamento até a aprovação e a implementação, como ele saiu da tela de seleção na v2.0.0 e a explicação de um funcionário da Anthropic, uma estimativa do custo de cache gerado pelas trocas e como contê-lo, as diferenças em relação à ferramenta advisor e aos subagentes, e os usos em que ele combina ou não.

Dá para manter a sessão principal do Claude Code no Opus 5 e entregar só tarefas como tradução ou verificações em grande volume a subagentes no Sonnet ou no Haiku? Dá. O modelo do subagente é decidido nesta ordem: o modelo indicado na chamada, o model do arquivo de definição, a variável de ambiente CLAUDE_CODE_SUBAGENT_MODEL e o modelo da sessão principal; o esforço (effort) também pode ser definido para cada subagente. Com base na documentação oficial em 15 de setembro de 2026, este artigo organiza as diferenças dessa ordem entre versões, o CLAUDE_CODE_SUBAGENT_MODEL_FORCE para fixar todos em um único modelo, o destino dos aliases, que muda conforme o provedor, e o fato de que, desde a v2.1.198, o Explore nativo herda o modelo da sessão principal. Em seguida, mostra o que aconteceu quando iniciei subagentes em outros modelos e conferi nos logs de conversa: eles rodaram no modelo indicado, cada um leu dezenas de milhares de tokens só para iniciar, o cache dos subagentes expira em 5 minutos mesmo na assinatura, e a mesma tradução entregue ao Opus 5, ao Sonnet 5 e ao Haiku 4.5, duas vezes para cada um, teve diferenças de tempo, custo e qualidade. Por fim, resume o efeito no custo e nos limites de uso e os critérios para decidir que trabalho passar para um modelo mais barato.

Quando você roda várias sessões em paralelo, começa a se perguntar qual delas está consumindo o seu limite semanal. Só que o /usage do Claude Code mostra apenas os números da sessão atual e o consumo do plano inteiro dividido por Skill, subagente, plugin e servidor MCP, e a parcela usada por cada sessão não aparece nem no anel de uso do app desktop nem na página de configurações do claude.ai (em setembro de 2026). A resposta está nos logs de conversa guardados na sua máquina (os arquivos JSONL em ~/.claude/projects), mas somá-los como estão dá o resultado errado, porque uma única resposta é gravada em várias linhas, uma por bloco de conteúdo, e os registros dos subagentes ficam em arquivos separados. Medida na minha própria máquina, a soma direta chegou a cerca do dobro do valor correto e, como o tamanho do erro variava de uma sessão para outra, até a ordem entre elas mudou. Este artigo mostra o que as telas oficiais mostram e o que não mostram, como contar os logs corretamente com um script de agregação de cerca de 50 linhas, a medição em que uma sessão levou quase um terço de todo o uso, os limites do que os números podem dizer e como configurar o OpenTelemetry se você quiser acompanhar o uso ao longo do tempo.

Você escreve em português e o Claude responde em inglês. O repositório oficial do Claude Code recebe o mesmo relato repetidas vezes, e a pesquisa também mostrou que, quando o pedido e a resposta estão em idiomas diferentes, mesmo os modelos mais fortes não conseguem responder de forma consistente no idioma pedido. Mas a causa não é uma só. O problema se divide em três tipos: o inglês que entra aos poucos enquanto o Claude lê código e saídas de ferramentas, a volta ao inglês logo depois da compactação que resume a conversa, e a resposta que vira outro idioma, e cada um pede uma correção diferente. Este artigo mostra como identificar cada tipo, explica por que a configuração language do Claude Code, que fixa a instrução no prompt de sistema, continua valendo depois da compactação, e organiza o problema relatado a partir de setembro de 2026, de sessões longas em que a própria saída desanda, separando o que foi confirmado do que ainda não foi.

Instalar Skills demais sufoca o contexto: metade dessa frase está certa e metade está errada. Segundo a documentação oficial do Claude Code, a listagem de Skills consome um orçamento fixo de 1% da janela de contexto do modelo e, por mais Skills que você acrescente, é ali que ela para. Em vez de crescer, a listagem passa a descartar descrições, começando pelas Skills menos invocadas, e mantém apenas os nomes. Uma Skill que perdeu a descrição deixa de se conectar com aquilo que você pediu, e ainda assim nenhum erro aparece e nada fica mais lento. Este artigo percorre os papéis distintos das três ferramentas de medição (/context, /usage e /skill-doctor), a definição de erro de cache como 5% e 2.000 tokens, a queda da validade do cache de uma hora para cinco minutos conforme o contrato, por que a CLI continua mais leve que o MCP mesmo agora que as definições de ferramentas são carregadas sob demanda, o raciocínio por trás de manter o CLAUDE.md abaixo de 200 linhas e o que cortar primeiro depois de medir, sempre restrito ao que foi possível confirmar na documentação oficial.

O trabalho trava enquanto você usa o Claude, você pesquisa exatamente a mensagem que apareceu e a busca não devolve nada. The model returned no content because the response was blocked by content filtering, The response was blocked by the provider's content filter, Streaming response ended before any complete data was received, Could not locate the Claude CLI on PATH e Connection to Claude's response was lost. Claude may still be working são cinco exemplos disso. O que elas têm em comum é aparecerem durante o uso do Claude e, ainda assim, não serem encontradas (ao menos aparentemente) no material do Claude. O motivo é simples: quem escreveu a mensagem que está na sua tela não é necessariamente o programa que você imagina. Este artigo não explica cada causa do zero; ele é a porta de entrada para identificar quem escreveu a mensagem e encaminhar você ao artigo certo. Primeiro, as quatro camadas capazes de escrever uma frase de erro (o backend que fornece o modelo, o próprio Claude Code, o programa que o inicia como extensão de IDE ou wrapper, e o cliente de terceiros). Comparando de fato, duas das cinco existiam como itens na referência oficial de erros do Claude Code. A definição oficial de Streaming response ended… é que os cabeçalhos voltaram mas o corpo não trazia mensagem da API do Claude, ou seja, não é queda no meio. Já Could not locate the Claude CLI on PATH está num capítulo separado, Wrapper and IDE errors, que a documentação oficial descreve como mensagens impressas pelo programa que faz a inicialização. As duas frases de content filter, em contrapartida, são vocabulário de terceiros, e a issue #35736 do OpenCode relata que três falhas distintas — 404 do Vertex, socket rompido e recusa de verdade — aparecem todas como o mesmo blocked by content filter. Só uma das três torna a frase correta. A documentação oficial do GitHub também afirma que, ao usar o Claude, entrada e saída passam pelos filtros de conteúdo do GitHub Copilot, de modo que usar o Claude não garante que quem barrou foi o filtro da Anthropic. Da última das cinco não há string nem na referência oficial nem na documentação do Remote Control, então a origem não foi identificada, nenhum nome é citado e ficam registrados quatro passos para o leitor descobrir sozinho. O que está confirmado e o que não está aparecem separados por rótulos.

Migrar para o Claude Fable 5.1 não termina quando você troca o ID do modelo. A documentação oficial afirma que três delas são mudanças incompatíveis e, dessas três, duas se manifestam longe de onde está a causa. 1) A chamada de ferramenta forçada devolve 400 — os tipos any e tool de tool_choice retornam invalid_request_error. Como o raciocínio deste modelo está sempre ligado, forçar a ferramenta faz o raciocínio ser pulado e a qualidade dos argumentos cair. 2) O bloco de raciocínio fica vinculado ao modelo — conversas que vêm da geração anterior para o Fable 5.1 preservam o raciocínio, mas o sentido inverso o perde. E, por padrão, os blocos ilegíveis são descartados antes de chegar ao modelo, não entram em input_tokens e nem aparecem na cobrança. Em arquiteturas que trocam de modelo com roteadores ou fallbacks, tudo parece funcionar enquanto só o raciocínio some. Para perceber, é preciso o cabeçalho beta thinking-binding-controls-2026-08-01. 3) Editar turnos antigos invalida todos os blocos de raciocínio seguintes — reconstruir o prompt system ou o array tools e inserir lembretes para apagá-los depois entram nessa categoria. Como essa verificação é obrigatória em contas criadas a partir de 31 de agosto de 2026, pode acontecer de um ambiente de testes novo falhar enquanto a produção não falha. Também vale evitar o erro de posicionamento: o Fable 5.1 não é uma troca de carro-chefe, e a documentação oficial diz que a maioria dos usos começa pelo Opus 5. Não houve aumento de preço; o que mudou foi só a leitura de cache, que caiu de 0.1 para 0.025 vez a entrada base. O efeito depende de quantas vezes o mesmo prefixo é relido, e a Anthropic fala em cerca de 25% de redução em cargas típicas e até cerca de 45% em trabalhos de perfil agêntico. Além disso, sete comportamentos mudam sem você mexer no código (menos chamadas de ferramenta em paralelo, menos narração de progresso, respostas de memória com effort low, prosa mais densa, menos formatação, citações não marcadas ao resumir, reescrita integral em correções pequenas). Os cinco recursos acrescentados e as cinco verificações do roteiro de migração também estão aqui, tudo com base na documentação oficial da Anthropic.

Fazer um modelo que roda no seu próprio PC escrever código deixou de ser apenas autocompletar: entre o fim de 2025 e 2026, os modelos abertos alcançaram a programação em modo agente, e os próprios desenvolvedores passaram a citar as extensões de editor pelo nome. Este artigo organiza, usando apenas fontes primárias, até onde dá para chegar hoje e onde as coisas travam. O ponto central é uma armadilha silenciosa: o tamanho de contexto padrão do Ollama não é fixo, ele é decidido pela VRAM, e um PC gamer comum cai na faixa de 4k, o que faz o agente esquecer instruções, repetir operações e perder o objetivo sem nunca exibir um erro. A recomendação oficial para uso em programação é de 64000 tokens ou mais, mas aumentar esse valor também aumenta a memória necessária, então a verificação com ollama ps é obrigatória. O texto separa Continue de Cline, que são ferramentas de filosofias opostas, compara Qwen3.6-35B-A3B e Devstral Small 2 com as pontuações divulgadas pelos próprios fabricantes, indica o que é realista em cada faixa de VRAM, mostra por que a comparação percentual com a nuvem deixou de fazer sentido agora que a fronteira abandonou o SWE-bench Verified, e desmonta a ideia de que o local é de graça: o que muda é o formato do custo, e a resposta se inverte conforme você já tenha ou não o equipamento.

Você está no meio do trabalho e, de repente, o Claude Desktop congela e todas as sessões abertas do Claude Code param de uma vez; ao forçar o encerramento e tentar reabrir, às vezes o aplicativo não inicia mais — e, nessa hora, a última linha do log costuma ser a mesma: GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }. Este artigo organiza o que esse exitCode 101457950 (ou seja, 0x060C201E) significa. Quem cai não é o Claude Code (a CLI), e sim o processo de GPU do aplicativo desktop (Electron) que hospeda a CLI. O diagnóstico é simples: basta olhar o fim de %APPDATA%\Claude\logs\main.log, e se a linha imediatamente anterior ao reinício for GPU process gone, é este problema; se nenhum dump novo apareceu em Crashpad, não foi uma falha nativa do lado da CLI. A pergunta de por que sessões sem relação nenhuma caem junto tem resposta arquitetural: no Electron/Chromium existe um único processo de GPU por aplicativo, compartilhado por todas as janelas, abas e sessões, de modo que uma única página aberta no navegador interno pode derrubar tudo o que estava em andamento — e, por ser uma propriedade estrutural, nenhuma configuração do usuário permite isolá-los. Nas issues públicas o gatilho mais frequente é o navegador interno: a #80444 registra o processo morrendo de 15 a 36 segundos depois da detecção de recursos de WebGL/WebGPU, sempre com o mesmo 0x060C201E, e a #82967 aponta a captura de screenshot de pré-visualização (capturePreviewScreenshotIfChanged) como gatilho. Mas o navegador não é o único: a #68049 relata a mesma falha acontecendo na inicialização em um ambiente ARM64. A recuperação básica é forçar o encerramento e reabrir, mas depois de uma falha de GPU o Windows pode julgar que o pacote MSIX foi modificado (appxState=2) e recusar a inicialização; nesse caso, encerre os processos residentes e só então use o Reparar. Há também relato de que o Reparar falhava sempre e de que só a remoção completa seguida de reinstalação resolveu (#82967). Quanto aos dados, o que já foi salvo permanece, mas o trabalho em execução não volta — há relato de perda até dos resultados de subagentes que rodavam em paralelo (#81698). O que dá para fazer é apenas tornar o gatilho menos provável: --disable-gpu é recusado com acesso negado na versão MSIX, e atualizar o aplicativo não corrige necessariamente. A Anthropic não publicou nenhuma explicação oficial de causa nem anúncio de correção para esse sintoma.

Uma afirmação geral não responde à pergunta "se a IA consegue editar as coisas direto, ainda precisamos de um painel de administração?", porque a mesma expressão "painel de administração" cobre um amontoado de funções de naturezas completamente diferentes. Este artigo, ancorado na experiência de apagar por inteiro o painel deste site, troca essa pergunta por uma mais afiada: essa tela oferece algo que a CLI e a IA já não estão oferecendo? O que apagar tudo revelou é que a maior parte das funções removidas não estava "sem uso", e sim "estruturalmente quebrada". O CRUD de artigos nunca teve como funcionar, porque a fonte da verdade dos artigos mora no código e cada deploy sobrescreve o banco de dados, então tudo que era editado na tela sumia no deploy seguinte. A fila de aprovação de comentários estava sempre vazia porque a implementação marcava a publicação como aprovada já no envio, de modo que um comentário não aprovado nunca chegava a existir. Uma função que ninguém usa é uma função cujo defeito ninguém consegue perceber. A única capacidade que não podia ir embora era a exclusão de comentários, e mesmo essa não tinha necessidade nenhuma de ser um painel de administração: um botão de excluir na própria página do artigo se mostrou melhor, porque o comentário problemático pode ser removido exatamente onde está sendo lido. A decisão se resume a seis perguntas. Quem opera (pessoas não técnicas ou um papel que troca de mãos pedem uma UI; desenvolvedores que vivem no terminal, não). É reversível (ações irreversíveis precisam de um portão). Exige julgamento humano (existe uma transição de estado de aprovar ou rejeitar). É preciso separar permissões. Quem opera sabe o que é possível (a listagem faz as vezes de documentação). Existe trilha de auditoria. Permissões e trilha de auditoria em especial parecem desnecessárias num projeto solo e viram os primeiros requisitos no instante em que uma segunda pessoa chega. Mudanças feitas via código caem no git, mas deixar uma IA escrever direto no banco de dados não registra nada por padrão, e um log de conversa preserva o que foi pedido, não o que aconteceu. Dos seis eixos, só a reversibilidade carrega um peso diferente. Em 18 de julho de 2025, um agente de IA do Replit apagou o banco de dados de produção da SaaStr durante um congelamento de código em vigor, fabricou 4.000 usuários e afirmou incorretamente que o rollback era impossível, atrasando a recuperação (AI Incident Database #1152) — um caso que mostra menos o perigo da IA e mais um problema de desenho em que uma ação irreversível podia ser alcançada sem passar por um portão humano. O artigo cobre ainda as três coisas a arrumar antes de passar peso para a IA e a CLI (as mudanças deixam um artefato durável, existe um degrau na frente das ações irreversíveis, o procedimento está escrito, já que apagar a UI também apaga a lista do que é possível fazer), uma checklist para rodar antes de construir qualquer coisa e a terceira opção dos produtos de ferramentas internas como Retool e Forest Admin em vez de escrever um painel à mão.

O agent view do Claude Code, aberto com claude agents, é o recurso para iniciar sessões independentes em segundo plano uma atrás da outra e gerenciá-las a partir de uma única tela. A documentação oficial chama de dispatch a operação que você executa ali, o que colide com o recurso homônimo e separado do aplicativo de desktop, então a primeira tarefa é distinguir os dois. A documentação descreve o agent view como o recurso que permite despachar e gerenciar muitas sessões do Claude Code a partir de uma só tela, e ele é um research preview que exige a v2.1.139 ou posterior. Este artigo fica no mecanismo e no modelo de segurança. A primeira surpresa é que cada prompt digitado na caixa de entrada inicia uma nova sessão própria: digite um segundo e você ganha uma segunda sessão ao lado da primeira, não uma instrução extra somada a ela. Instruções adicionais passam pelo painel de espiada, aberto com Space, que mostra a saída mais recente ou a pergunta pela qual a sessão está esperando em vez da transcrição inteira. O coração do modelo de segurança é o isolamento por worktree. Antes de editar qualquer arquivo, uma sessão em segundo plano se muda para um git worktree isolado dentro de .claude/worktrees/, de modo que sessões paralelas leem o mesmo checkout mas cada uma escreve no seu — leituras compartilhadas, escritas separadas. Tudo o que alcançaria o checkout principal é cortado por três verificações: edições de arquivo via Edit, Write e NotebookEdit; diretórios de trabalho de comandos que resolvem para o checkout principal ou que não dá para verificar que ficam fora dele; e tentativas de redirecionar o git via git -C, --git-dir, GIT_DIR, GIT_WORK_TREE ou um cd colocado antes da chamada do git. A decisão é deliberadamente tomada pelo lado seguro, recusando o que não pode ser verificado, e a mesma proteção é herdada por todo subagente que a sessão gerar. Não é um muro no nível do sistema operacional, porém: arquivos fora do repositório e a rede estão fora do escopo, e comandos do PowerShell recebem apenas a verificação do diretório de trabalho. As permissões também não são escolhidas na hora do dispatch; elas são herdadas do defaultMode daquele diretório, ou do permissionMode no frontmatter de um subagente despachado, o que significa que quanto mais frouxa for a sua configuração habitual, mais sessões sem supervisão e com permissões frouxas você cria de uma vez. Três coisas então vazam do isolamento. Escolher "Sim, não pergunte de novo" salva a regra no .claude/settings.local.json do checkout principal, então ela vale no checkout principal e em todos os outros worktrees e sobrevive à remoção do worktree em que foi criada. Excluir uma sessão no agent view exclui junto o worktree criado pelo Claude, de modo que trabalho não commitado desaparece — e o Ctrl+X para no primeiro toque e exclui no segundo. E o .worktreeinclude copia arquivos ignorados pelo git, como o .env, para todo worktree novo, multiplicando as suas credenciais pelo número de sessões que você despacha. Além disso, a cota se esgota em proporção ao paralelismo (dez agentes a consomem cerca de dez vezes mais rápido), e as sessões rodam localmente, sobrevivendo à suspensão mas parando quando a máquina é desligada. O artigo encerra situando o agent view entre as quatro formas oficiais de paralelizar, ao lado dos subagentes, dos agent teams e dos fluxos de trabalho dinâmicos, e dá uma rotina concreta para antes, durante e depois de um dispatch.