Onde o agente mora: por que a corrida dos harnesses de código migrou da IDE para a topologia de execução

Durante anos, a discussão sobre inteligência artificial no desenvolvimento girou em torno de qual modelo acertava mais testes sintéticos ou respondia mais rápido no editor. Em novembro de 2026, quando os principais modelos já entregam raciocínio parecido em tarefas de programação, o risco prático mudou de lugar: quem decide se a operação é segura, auditável e previsível no orçamento não é apenas o modelo, mas o harness — a camada de software que controla onde e como o agente trabalha.

Na prática, o harness funciona como o ambiente operacional em volta do modelo: seleciona os arquivos que entram no contexto, expõe ferramentas de leitura e escrita, pede aprovação humana, guarda o histórico e isola a execução de comandos e testes. Quando um agente apaga arquivos fora do projeto, instala pacotes descontinuados ou entra em ciclos repetidos que consomem créditos sem entregar código útil, o problema raramente está só na capacidade do modelo. Está em um harness que não limitou permissões, processos ou consumo.

Ao mesmo tempo, refatorações longas e migrações trouxeram uma necessidade operacional concreta: disparar e acompanhar tarefas a partir de notebooks leves, tablets ou celulares sem depender do computador da mesa ligado o dia inteiro. Essa necessidade expõe a decisão central para gestores e líderes técnicos: separar onde a pessoa acompanha o trabalho, onde o ciclo de controle toma decisões e onde o código realmente roda define se a organização entrega repositório e credenciais a um serviço externo ou mantém a execução sob governança própria.

Anatomia de um harness moderno e a tabela-eixo

Todo harness de código pode ser decomposto em três camadas:

1. Camada de interação (cliente): superfície onde a pessoa envia instruções, revisa alterações e aprova etapas — terminal (CLI/TUI), janela de editor desktop (Electron), navegador web ou aplicativo móvel.
2. Camada de orquestração (daemon / ciclo do agente): motor que chama a API do modelo, mantém o estado da sessão, controla o orçamento de contexto (prompt caching e compactação de histórico) e aciona ferramentas por protocolos abertos como o Model Context Protocol (MCP).
3. Camada de execução (sandbox): ambiente onde os comandos alteram o disco, aplicam diffs e rodam compiladores, linters e suítes de teste.

A combinação de onde cada uma dessas três camadas reside define os quatro arquétipos comparados na tabela abaixo:

flowchart TD
    subgraph Local["Ambiente Local do Desenvolvedor"]
        direction TB
        UI["1. Interface do Usuário (CLI / TUI / IDE Electron)"]
        DaemonLocal["2. Daemon Local (Sessão, MCP, Cache)"]
        SandboxLocal["3. Sandbox Local (Kernel Namespaces / Worktrees)"]
        Repo[("Repositório Git Local")]
        UI --> DaemonLocal --> SandboxLocal --> Repo
    end

    subgraph Nuvem["Nuvem do Provedor / Servidor Remoto"]
        direction TB
        Relay["Relay de Conexão Móvel"]
        LLM["Provedor do Modelo (LLM API)"]
        VMCloud["VM Isolada (SaaS Autônomo)"]
    end

    UI -.->|"Remote Control"| Relay
    DaemonLocal <-->|"Inferência"| LLM
    Relay -.->|"Pareamento (host acordado)"| DaemonLocal
    Relay -->|"Sessão desacoplada"| VMCloud

A fronteira da custódia: Soluções de SaaS autônomo eliminam a obrigação de manter a estação de trabalho ligada, mas transferem o repositório, variáveis de ambiente e o histórico de execução para infraestruturas de terceiros. A escolha do harness define, primariamente, onde a organização autoriza que seus segredos residam durante a inferência.

Cada arquitetura resolve uma parte do problema e cobra sua conta em outra moeda.

Os harnesses dos grandes laboratórios: verticalização, subagentes e vínculo de ecossistema

Anthropic, Google e OpenAI convergiram para o mesmo desenho estrutural: ferramentas oficiais capazes de operar direto sobre os arquivos, o terminal e o Git da máquina do desenvolvedor — por linha de comando ou aplicativo desktop —, combinadas a subagentes paralelos e modos complementares em nuvem, sempre ajustadas à família de modelos e aos planos de assinatura de cada fabricante.

Anthropic: Claude Code e o agente centrado no terminal

Distribuído sob @anthropic-ai/claude-code (versão 2.1.318 em 04/11/2026 no registro npm), o Claude Code consolidou o uso de agentes na linha de comando. A instalação via npm foi descontinuada no README do repositório em favor de instaladores nativos (brew install --cask claude-code e winget install Anthropic.ClaudeCode), conforme o guia de instalação.

Na documentação sobre como o Claude Code funciona, a Anthropic define agentic harness como a camada em torno do modelo que provê ferramentas e governa o contexto visível, separando três modos: Local (padrão, na máquina do usuário com acesso integral aos arquivos), Cloud (VMs gerenciadas pela Anthropic ou pela organização) e Remote Control (janela web ou móvel sobre a sessão local).

Na página do Remote Control (claude.ai/code e apps iOS/Android), a dependência física e comercial fica explícita: toda execução de código e leitura de disco permanece na máquina local, exigindo computador ligado e processo claude ativo; além disso, o recurso exige planos Pro, Max, Ultra, Team ou Enterprise (com ativação prévia por um Owner nos dois últimos) e não aceita chaves de API.

Nossa leitura: equipes que pagam apenas consumo direto de API ficam sem o Remote Control oficial e precisam recorrer a túneis SSH com tmux ou zellij para trabalhar longe da mesa.

Em compensação, o controle vertical favorece o Prompt Caching — que guarda em cache o prefixo exato da requisição em três blocos (instruções de sistema, CLAUDE.md e histórico), invalidando-o apenas se a base mudar — e inclui sandboxing opcional (/sandbox, desligado por padrão) com Seatbelt no macOS e bubblewrap no Linux/WSL2, sem equivalente em Windows nativo.

sequenceDiagram
    autonumber
    actor Dev as Desenvolvedor (Celular / Web)
    participant Relay as Nuvem do Provedor (Relay / Auth)
    participant Host as Estação de Trabalho (Processo Ativo)
    participant Sandbox as Sandbox do SO / Arquivos

    Dev->>Relay: Inicia instrução na interface móvel
    Relay->>Host: Encaminha comando via WebSocket seguro
    activate Host
    Note over Host: Exige computador ligado e processo do harness ativo
    Host->>Sandbox: Aplica diff / Executa comando no terminal
    Sandbox-->>Host: Retorna saída e resultado dos testes
    Host-->>Relay: Stream de telemetria e diffs gerados
    deactivate Host
    Relay-->>Dev: Renderiza alterações no aplicativo móvel

A dependência física do pareamento: O modo Remote Control oferece mobilidade na interface, mas mantém o acoplamento físico com a máquina de desenvolvimento. Se o computador entrar em suspensão ou perder a conexão de rede local, o ciclo do agente é imediatamente interrompido.

Google: Antigravity e o isolamento concorrente de subagentes

O Google organizou o Google Antigravity em aplicativo desktop Electron (v2.5+), linha de comando agy (v1.2+, na referência da CLI), extensões de editor e kit Python em google-antigravity/antigravity-sdk-python, combinando modelos Gemini a provedores parceiros curados (como Claude e GPT-OSS 120B, descritos em modelos suportados) e sandbox de terminal ativa por padrão (Seatbelt no macOS, Namespaces no Linux e suporte a Windows 11 24H2+).

A principal escolha arquitetural do produto é dividir tarefas em sessões paralelas com contexto separado por meio de invoke_subagent, conforme a documentação de subagentes. Ao acionar um subagente, o agente principal define o modo de diretório — compartilhar o mesmo espaço (inherit), abrir uma ramificação isolada do Git (branch) ou dividir o armazenamento (share) — e escolhe o porte do modelo, mas o subagente parte com janela de contexto limpa, sem carregar o histórico acumulado da conversa principal.

O ambiente traz subagentes prontos (como research) e permite declarar novos tipos com define_subagent, trocando mensagens por send_message. Integrado ao Model Context Protocol (MCP), utiliza reativação orientada a eventos (Reactive Wakeup): ao iniciar comandos demorados com run_command (WaitMsBeforeAsync), suspende o turno sem laços de espera ativa (sleep) e retoma o trabalho quando recebe o aviso de término, uma mensagem ou um agendamento (schedule).

Para uso fora da estação, além dos Remote Agents em nuvem (em liberação gradual para assinantes Google AI Pro e Ultra), o Remote Control oferece acesso autenticado pela Conta Google sobre sessões desktop e CLI em execução nas máquinas do desenvolvedor — mantendo arquivos e ferramentas no computador local.

OpenAI: o Codex incorporado ao aplicativo ChatGPT, à CLI e à nuvem

Na OpenAI, convém separar a geração original do Codex (pesquisa apresentada em 2021 por Chen et al., arXiv:2107.03374, cujos endpoints de autocompletar code-davinci-* e code-cushman-* tiveram a retirada anunciada em março de 2023 e concluída em 4 de janeiro de 2024 no registro de descontinuações) do harness atual. Longe de abandonar o produto, a empresa reconstruiu o Codex como ambiente agêntico completo e incorporou-o diretamente ao aplicativo ChatGPT — disponível no desktop para macOS e Windows (versão nativa para Windows) e em versão prévia para distribuições Linux —, em conjunto com a Codex CLI (@openai/codex 0.166.0 no registro npm; release rust-v0.166.0 sob licença Apache-2.0 em openai/codex), extensões de IDE e o Codex Cloud.

Dentro do aplicativo desktop, conforme o guia de uso do ChatGPT, o seletor principal alterna entre Chat, ChatGPT Work e Codex — este último abre uma interface de desenvolvimento com projetos, visualização de diffs, painel de pull requests e terminal integrado. O funcionamento é semelhante ao do Antigravity em duas frentes. Primeiro, no isolamento de diretórios descrito em ambientes do Codex e Git worktrees: cada conversa roda na pasta atual (Local), em uma árvore isolada sob $CODEX_HOME/worktrees (Worktree, retendo até 15 cópias recentes por padrão e movendo alterações ao checkout local por Handoff) ou em um ambiente publicado na nuvem (Cloud). Segundo, na delegação concorrente detalhada em subagentes: habilitados por padrão no aplicativo, na CLI (/subagents) e na IDE, subagentes paralelos dividem buscas, testes e revisões — combinando modelos como gpt-6.1-sol e gpt-6-luna e regras hierárquicas em AGENTS.md — e retornam resumos consolidados para preservar a janela principal de contexto.

No confinamento local (documentação de sandbox), os comandos do aplicativo, da CLI e da IDE rodam por padrão em workspace-write com aprovação na fronteira (on-request), aplicando isolamento nativo nos três sistemas: Seatbelt no macOS, bubblewrap (bwrap) no Linux/WSL2 e sandbox nativa de Windows em PowerShell sobre Microsoft Execution Containers (mxc). No uso móvel pelo app do ChatGPT, o usuário inicia tarefas no Codex Cloud ou pareia por QR code um Mac ou PC (conexões remotas) para aprovar ações e revisar diffs — com a mesma trava física para arquivos locais: se o computador dormir ou fechar o app, o acesso cessa, salvo em máquinas permanentes ou hosts SSH rodando o codex app-server. Na autenticação e nos planos, embora o motor local aceite chave de API (codex login --with-api-key) e provedores customizados (como Ollama) em config.toml, tanto o Codex Cloud quanto o controle remoto pelo celular exigem assinatura elegível (Plus por US$ 20, Pro em US$ 100/200/500, Business a partir de US$ 20/usuário/mês no plano anual ou Enterprise, ficando Free e Go de US$ 8 restritos ao GPT-6 Luna no desktop).

Nossa leitura: os três laboratórios chegaram a harnesses locais maduros — com destaque para o paralelismo de subagentes, sandboxes nativas e worktrees no Antigravity e no Codex dentro do aplicativo ChatGPT —, mas cobram um pedágio estrutural parecido. Os fluxos oficiais de nuvem e de controle pelo celular exigem planos pagos por usuário (vedando chaves avulsas de API) e continuam dependendo de uma máquina hospedeira acordada sempre que a tarefa remota precisa atuar sobre o repositório local.

O SaaS totalmente gerenciado na nuvem: conveniência e opacidade no Devin

O segundo arquétipo transfere interface, controle, testes e cópia do repositório para a nuvem do fornecedor. No Devin, da Cognition AI (hospedado na AWS), o desenvolvedor ganha mobilidade imediata em qualquer tela sem manter máquina própria ligada.

Arquitetura em nuvem: ambientes padronizados e imagens congeladas

Segundo a documentação de ambiente do Devin, cada espaço de trabalho é uma VM Linux completa com repositórios clonados, compiladores, dependências, variáveis e credenciais do projeto. Toda sessão parte de uma imagem congelada (snapshot), descartando ao final o que não for enviado ao Git sem alterar a base.

O acompanhamento ocorre via app.devin.ai, Slack ou GitHub. Ao assumir o controle manual (takeover), o engenheiro acessa terminal, VS Code em nuvem e navegador Chromium com transmissão de tela, descritos em ferramentas de sessão e na introdução do produto.

Cobrança por ACU e impacto financeiro na operação

Conforme medição de uso, planos diretos e faturamento corporativo, o consumo é medido em Agent Compute Units (ACUs): planos diretos descontam da franquia mensal e de créditos pré-pagos (Free por US$ 0, Pro por US$ 20, Max por US$ 200 e Teams a partir de US$ 80/mês), enquanto as Enterprise ACUs seguem regras contratuais próprias. Ambientes Windows consomem cerca de 9% mais que sessões Linux (Ubuntu), e a VM suspende o gasto automaticamente após 30 minutos ociosos por padrão.

Segurança, guarda de dados e restrições de uso

Na página de segurança administrativa, a Cognition informa certificação SOC 2 Tipo II desde setembro de 2024. Nos planos diretos, porém, a empresa pode por padrão usar dados das sessões para treinar seus serviços: assinantes pagos precisam desligar a opção manualmente em Data Controls para ativar retenção zero (ZDR), enquanto apenas contratos Enterprise vedam treinamento por padrão sem aval escrito. O código gerado pertence ao cliente, salvo a proibição contratual de usá-lo para treinar modelos concorrentes ou fazer engenharia reversa do Devin.

Nossa leitura: o Devin entrega trabalho assíncrono imediato no navegador ou tablet, mas cobra em previsibilidade financeira — já que a ACU esconde o custo real de tokens — e exige aceitar código-fonte e chaves de desenvolvimento na nuvem do fornecedor.

A IDE local-first: controle na bancada e atrito remoto no Cursor

O terceiro arquétipo mantém o editor instalado na estação do desenvolvedor. O Cursor, da Anysphere (derivado do VS Code sobre Electron), preserva os arquivos localmente, mas esbarra em limites físicos fora do computador principal.

Execução local, Agents Window e pontos de restauração

Segundo a ferramenta de terminal e a visão geral do agente, o Cursor executa comandos direto no shell do usuário conforme a política configurada. No Cursor 3 (02/04/2026), a Agents Window passou a coordenar agentes paralelos entre projetos locais, nuvem e SSH, gravando pontos de restauração (Checkpoints) locais fora do Git para reverter edições do agente.

Modos de execução e diferenças de isolamento entre sistemas

Os Run Modes (modos de execução) dividem-se em Auto-review (padrão desde a v3.6), Allowlist e Run Everything. A própria Anysphere adverte que o Auto-review não é uma fronteira rígida de segurança, pois o classificador remoto (Gemini 3.5 Flash Lite, com Claude 4.5 Haiku de contingência) pode liberar chamadas indevidas ou barrar comandos legítimos, enquanto ferramentas locais (ReadFile, Grep, Glob, ListDir) leem o disco (com escopo Workspace ou System via Read Access desde a v3.23, de 01/10/2026).

O isolamento de sistema operacional varia por plataforma:

• macOS: perfis dinâmicos no Apple Seatbelt (sandbox-exec), restringindo arquivos, rede e processos filhos.
• Linux: Landlock v3 e seccomp, exigindo kernel 6.2+ com CONFIG_SECURITY_LANDLOCK=y e user namespaces ativos.
• Windows: não há isolamento de kernel documentado para comandos do agente no Windows, restando apenas listas de permissão ou confirmação manual.

Limites do aplicativo móvel e do Remote Control

A documentação do Cursor para iOS (iOS 26.0+) esclarece que o app móvel serve apenas para orientar agentes e revisar diffs, deixando editor, terminal e árvore de arquivos restritos ao desktop ou a cursor.com/agents. Já o Remote Control (v3.9.8+, exclusivo da Agents Window) roteia o controle pela nuvem mantendo a execução na máquina local. O Privacy Mode veda treinamento e vem ativo por padrão no plano corporativo (privacidade Enterprise), com faixas Free, Plus (US$ 8), Premium (US$ 30), Super (US$ 100), Ultra (US$ 200) e Teams (US$ 30 a US$ 200/usuário) em modelos e preços.

Nossa leitura: o Cursor mantém o código na bancada com a experiência familiar do VS Code, mas se o notebook fechar a tampa ou perder rede, a sessão remota para. Continua sendo um editor desktop acoplado à nuvem, não um servidor autônomo.

Os servidores de código aberto (cliente-servidor): a separação limpa

O quarto arquétipo reúne projetos abertos que separam a interface de uso do processo que executa o trabalho. Ao rodar o agente como serviço em um servidor escolhido pela própria equipe, OpenHands, OpenCode e DeepSeek Harness permitem comandar tarefas pelo navegador móvel mantendo o repositório dentro de casa e pagando apenas os tokens consumidos direto na API do modelo (BYOK).

OpenHands: isolamento padrão em contêiner Docker

Mantido pela All-Hands AI sob licença MIT em OpenHands/OpenHands (versão estável v1.35.0 publicada em 03/11/2026 às 18h47 UTC, conforme a API de lançamentos do GitHub), o OpenHands adota contêineres como padrão de execução. Na página de sandboxes Docker, o projeto justifica essa escolha por dois motivos diretos: reduzir o risco quando o agente executa comandos e garantir um ambiente reproduzível entre máquinas diferentes.

O guia de personalização da sandbox detalha o funcionamento na versão V1: em vez de rodar comandos direto no sistema do usuário, o servidor do agente opera dentro de um contêiner baseado por padrão na imagem ghcr.io/openhands/agent-server:<release>-python, que já traz Python e Node.js pré-instalados.

O orquestrador disponibiliza uma interface web na porta 3000 (guia de instalação). Instalado em um servidor dedicado, permite acompanhar e aprovar tarefas pelo navegador de um tablet ou celular conectado via Tailscale, sem gastar bateria nem processamento do aparelho móvel. Na camada de modelos, utiliza a biblioteca LiteLLM (configuração de modelos), aceitando mais de 100 provedores de API e modelos locais (Ollama, vLLM) com chave própria.

OpenCode: servidor HTTP independente (opencode serve)

Desenvolvido pela Anomaly sob licença MIT em anomalyco/opencode (tag v1.19.5 no Git e pacote @opencode/cli na versão 2.2.5 no registro npm), o OpenCode nasceu estruturado como cliente e servidor separados.

Segundo a documentação de arquitetura do servidor, até mesmo o uso local no terminal segue esse desenho: o comando principal sobe simultaneamente um servidor HTTP (construído sobre Hono, com suporte a REST, SSE e especificação OpenAPI 3.1 usada para gerar o SDK) e a interface de texto (TUI), que atua apenas como cliente. Para manter o motor ativo de forma independente em uma VPS ou máquina interna, basta iniciar o processo dedicado:

opencode serve --hostname 0.0.0.0 --port 4096

Qualquer cliente pode se conectar passando --server http://<ip>:4096 ou abrindo a aplicação web: o comando opencode web inicia o servidor local em 127.0.0.1 numa porta livre e abre a interface completa no navegador, dispensando o terminal.

O serviço aceita senha via autenticação HTTP Basic (OPENCODE_SERVER_PASSWORD), controle de CORS e descoberta em rede local (--mdns). A integração com ferramentas externas via servidores MCP é declarada em opencode.json com regras granulares (ask, deny, allow), e o suporte a provedores cobre mais de 75 serviços por meio do Vercel AI SDK, guardando credenciais localmente em ~/.local/share/opencode/auth.json.

DeepSeek Harness: arquitetura modular de plugins e divisão roteador-operário

Publicado pela DeepSeek AI sob licença MIT em deepseek-ai/deepseek-harness (em versão prévia para desenvolvedores, Developer Preview) e distribuído como @deepseek-ai/dsh (0.2.1-rc.5 no registro npm), o DeepSeek Harness (DSH) parte da distinção explícita de que o agente equivale à soma entre modelo e harness: cabe ao modelo raciocinar e ao harness fornecer ferramentas, sessões, orquestração e limites de execução.

Construído sobre o framework Cordis, o projeto trata praticamente todos os componentes como extensões independentes: conectores de modelo (@deepseek-ai/dsh-llm-*), execução de comandos shell (@deepseek-ai/dsh-tool-bash), persistência de sessão e roteadores de eventos.

Para operação fora da estação de trabalho, o pacote traz um painel web nativo acionado pela CLI:

npx @deepseek-ai/dsh web

Por padrão, o comando sobe o painel na porta 3080 (http://127.0.0.1:3080). Com a opção --no-open, o serviço roda sem interface gráfica local (headless) em servidores internos ou VPS, podendo ser acessado por navegadores em tablets e celulares sobre Tailscale ou VPN privada.

No repositório experimental deepseek-ai/dsh-superagent-prototype, a equipe propõe reduzir o gargalo de supervisão humana separando dois papéis (Router-Worker):

1. Agente roteador (Router Layer): processo contínuo e leve que acompanha eventos do repositório (issues, comentários, pull requests ou canais de chat), confere quem enviou o pedido e decide se a tarefa deve ser aceita e dividida.
2. Agentes operários (Worker Agents): instâncias temporárias abertas em diretórios ou worktrees isolados para resolver um item específico, rodar os testes locais e abrir um pull request documentado.

Por padrão, o protótipo inicia em modo de observação (observe mode), exigindo aprovação humana antes de ações destrutivas ou fusões automáticas de código. Na escolha de modelos, aceita tanto a família DeepSeek (V3 e R1) quanto qualquer serviço compatível com o formato de API da OpenAI usando chave própria (BYOK).

Nossa leitura: os servidores de código aberto resolvem ao mesmo tempo os três pontos que costumam conflitar nas opções comerciais — acompanhamento móvel sem depender do notebook ligado, código-fonte mantido na infraestrutura escolhida pela equipe e pagamento direto pelo consumo real da API.

O custo real da operação própria: por que auto-hospedar não sai de graça

Se os servidores abertos permitem separar interface e execução mantendo o controle do código e da conta de API, por que tantas organizações continuam contratando o Devin ou padronizando o Cursor? Porque operar infraestrutura própria transfere para dentro de casa quatro custos concretos de segurança e sustentação:

1. Exposição do soquete do Docker: no OpenHands, o orquestrador costuma montar o soquete do Docker da máquina hospedeira (-v /var/run/docker.sock:/var/run/docker.sock), o que na prática equivale a conceder permissão de administrador (root) sobre o servidor. Se o agente sofrer uma instrução maliciosa escondida em código ou página externa (indirect prompt injection), um escape de contêiner pode atingir toda a máquina. Reduzir esse risco exige configurar Docker sem privilégios (rootless) ou micro-VMs dedicadas (Firecracker) — trabalho especializado de infraestrutura.
2. Consumo de memória e quedas silenciosas: enquanto OpenCode e DeepSeek Harness rodam como processos enxutos em Node.js/TypeScript, o OpenHands mantém em paralelo orquestrador, serviço FastAPI e contêineres completos de execução (ghcr.io/openhands/agent-server:<release>-python), consumindo vários gigabytes de RAM. Em servidores subdimensionados, tarefas simultâneas provocam encerramento abrupto por falta de memória (OOM) no meio de uma refatoração.
3. Rede privada e exposição de portas: abrir painéis web de agentes para acesso móvel exige manter rede privada (Tailscale ou VPN), proxy reverso com certificado TLS (Nginx ou Caddy) e autenticação ativa para evitar que um terminal com acesso ao código fique exposto à internet.
4. Horas de engenharia sênior no custo total (TCO): o tempo gasto por profissionais experientes cuidando de permissões de volumes, atualizações de imagens, quebras de versão e túneis de rede pode superar com folga o valor anual de licenças comerciais prontas.

Nossa leitura: manter um servidor próprio de agentes compensa em dois cenários claros — (a) profissionais e equipes técnicas com domínio de Linux e redes que querem mobilidade real pagando apenas o consumo de API; e (b) organizações sujeitas a exigências rígidas de sigilo ou regulação que não podem enviar repositórios e credenciais para nuvens compartilhadas de terceiros.

Como decidir na prática: matriz operacional

A escolha do harness precisa partir das restrições reais de segurança, orçamento e rotina de trabalho da equipe, e não da preferência visual por um editor.

Para o desenvolvedor individual e o consultor técnico sênior

• Estação dedicada acessível de qualquer tela: mantenha um computador compacto com Linux ou uma VPS simples (na faixa de US$ 10 a US$ 20/mês) rodando OpenCode (opencode serve --hostname 0.0.0.0), DeepSeek Harness (dsh web --no-open) ou OpenHands em contêiner, fechado dentro de uma rede Tailscale. Pelo navegador do tablet ou do celular, você dispara testes longos usando sua própria chave de API (BYOK), sem drenar bateria móvel nem deixar o notebook aberto na mochila.
• Trabalho concentrado na bancada: para quem atua na mesma estação e já adota a assinatura de um laboratório específico, o Claude Code, o Antigravity e o Codex (no aplicativo desktop do ChatGPT ou na CLI) operam direto sobre o sistema de arquivos e os worktrees locais com confinamento nativo e aproveitamento máximo de contexto dos respectivos modelos.

Para o líder técnico, gerente de engenharia e CTO

• Sigilo de código e conformidade regulatória: sob regras de sigilo bancário, saúde (HIPAA), proteção de dados (LGPD/GDPR) ou segredo industrial, planos diretos em nuvem pública com treinamento habilitado por padrão não atendem aos requisitos mínimos de governança. Os caminhos viáveis são o harness local sob contrato corporativo (como Cursor Enterprise com Privacy Mode obrigatório — atento à ausência de sandbox de kernel documentada no Windows — ou Codex local em ChatGPT Enterprise, que conta com sandbox nativa mxc no Windows) ou o servidor aberto em nuvem privada da própria empresa (OpenHands ou OpenCode em VPC interna, isolado por Firecracker ou Docker rootless).
• Previsibilidade financeira e auditoria: evite unidades fechadas de cobrança, como ACUs, em rotinas recorrentes de desenvolvimento. Conectar a camada de orquestração a um gateway interno (como LiteLLM Proxy) permite consolidar faturas por centro de custo, exigir retenção zero de dados (ZDR) dos provedores de modelo e registrar o histórico do que foi executado em cada repositório.

A capacidade bruta dos modelos ficou parecida e cada vez mais barata por chamada. O que separa uma adoção sustentável de um passivo de segurança ou de orçamento, daqui em diante, é decidir com clareza onde o agente mora.

Notas de método

Este artigo é uma análise documental baseada em especificações oficiais, código-fonte público e registros de pacotes. Não executamos testes próprios de carga nem medições em laboratório de latência, bateria ou consumo de memória; comportamentos e limites descritos reproduzem o que cada fabricante ou projeto documenta.

Snapshot de apuração em 04/11/2026:

• Anthropic Claude Code: pacote @anthropic-ai/claude-code na versão 2.1.318 no registro npm, documentação em code.claude.com/docs e repositório em anthropics/claude-code.
• Google Antigravity: CLI agy (v1.2+), aplicativo desktop (v2.5+), documentação em antigravity.google/docs e repositório em google-antigravity/antigravity-sdk-python.
• OpenAI Codex (aplicativo ChatGPT, CLI e Cloud): pacote @openai/codex na versão 0.166.0 no registro npm, repositório openai/codex (release rust-v0.166.0 de 29/10/2026, licença Apache-2.0), documentação em learn.chatgpt.com/docs, registro de descontinuações da API e artigo original de 2021.
• Cognition Devin: documentação em docs.devin.ai e portal em devin.ai.
• Anysphere Cursor: documentação em cursor.com/docs e central de ajuda em cursor.com/help.
• OpenHands: repositório OpenHands/OpenHands (versão estável v1.35.0 de 03/11/2026, licença MIT) e documentações em docs.openhands.dev e docs.all-hands.dev.
• OpenCode: repositório anomalyco/opencode (tag v1.19.5, branch dev, licença MIT), pacote @opencode/cli 2.2.5 no registro npm e documentação em opencode.ai/docs.
• DeepSeek Harness: repositório deepseek-ai/deepseek-harness (licença MIT), protótipo deepseek-ai/dsh-superagent-prototype, pacote @deepseek-ai/dsh (0.2.1-rc.5) no registro npm e documentação em deepseek-harness.github.io.

No texto, distinguimos afirmações retiradas das documentações e repositórios oficiais, versões conferidas em registros públicos (npm e GitHub) na data da apuração e interpretações arquiteturais nossas, sempre sinalizadas como nossa leitura. Citações originais em inglês das documentações consultadas foram parafraseadas em português mantendo os links diretos para conferência na fonte. Não foram utilizados relatos informais.

Ficaram fora do escopo comparativos de acerto de modelos isolados (como SWE-bench), tutoriais passo a passo de instalação e extensões restritas a preenchimento automático de linhas sem ciclo de execução de ferramentas.

A imagem de abertura foi gerada por IA a partir do assunto deste texto — superfícies leves de cliente conectadas a um anel de orquestração e a uma sandbox confinada —, sem rótulos, números ou marcas de terceiros. Funciona como cena conceitual de marca, não como captura ou diagrama de infraestrutura de nenhum produto citado.