OpenCode: o agente de código open source que passou de 200 mil estrelas

Se a categoria "agente de código no terminal" tinha dono — Claude Code de um lado, Codex do outro —, o OpenCode virou o terceiro nome impossível de ignorar. O projeto, mantido pela Anomaly no repositório anomalyco/opencode, se descreve em uma linha: the open source coding agent. E os números de 4 de setembro de 2026 dão peso à frase: 203,9 mil estrelas no GitHub, 26,6 mil forks, licença MIT e código em TypeScript, com atividade de push no mesmo dia da apuração.

Para um projeto criado em abril de 2025, é uma curva de adoção rara. Mas estrela no GitHub mede atenção, não qualidade — então vale olhar o que o OpenCode efetivamente é, como se instala, como organiza permissões e onde estão as ressalvas.

O que é o OpenCode

OpenCode é um agente de código que roda primariamente como TUI — uma interface de texto rica dentro do terminal, no mesmo território de uso do Claude Code. Você abre a ferramenta na raiz do repositório, conversa em linguagem natural, e o agente lê arquivos, propõe edições, executa comandos e itera sobre o resultado.

A diferença de posicionamento em relação aos concorrentes de laboratório está em dois pontos:

1. Aberto de ponta a ponta. Não é um cliente aberto para um serviço fechado: o agente em si é MIT, o desenvolvimento acontece em público e o repositório aceita contribuições (com um guia de contribuição formal antes de qualquer pull request).
2. Agnóstico de provedor. O OpenCode não está amarrado ao modelo de uma única empresa. Claude Code existe para vender Claude; Codex existe para vender os modelos da OpenAI. O OpenCode não tem esse compromisso estrutural — o modelo é uma peça configurável, não o produto.

Essa segunda característica é o argumento mais forte do projeto. Quem acompanhou 2025 e 2026 sabe que a liderança em modelos de código trocou de mãos mais de uma vez. Amarrar o fluxo de trabalho inteiro ao harness de um provedor significa refazer hábitos, atalhos e integrações a cada troca. Um harness neutro transforma a troca de modelo em mudança de configuração.

Distribuição madura, e isso diz algo

Um sinal de maturidade que costuma passar despercebido: de quantas formas dá para instalar a ferramenta. O README do OpenCode lista um cardápio incomum de canais:

# YOLO
curl -fsSL https://opencode.ai/install | bash

# Gerenciadores de pacote
npm i -g opencode-ai@latest         # ou bun/pnpm/yarn
brew install anomalyco/tap/opencode # macOS e Linux (tap recomendado)
brew install opencode               # fórmula oficial do brew (atualiza menos)
scoop install opencode              # Windows
choco install opencode              # Windows
sudo pacman -S opencode             # Arch Linux (estável)
paru -S opencode-bin                # Arch (AUR, mais recente)
mise use -g opencode                # qualquer SO
nix run nixpkgs#opencode            # Nix

Estar empacotado nos repositórios oficiais do Arch, no nixpkgs, no brew (tanto via tap próprio quanto na fórmula oficial), no scoop e no choco não acontece por acaso — exige releases estáveis o suficiente para mantenedores de distribuição confiarem no projeto. O próprio script de curl respeita uma ordem de prioridade documentada para o diretório de instalação ($OPENCODE_INSTALL_DIR, $XDG_BIN_DIR, $HOME/bin, $HOME/.opencode/bin), um detalhe pequeno que revela cuidado com quem administra a própria máquina.

Há ainda um app desktop em beta para macOS (Apple Silicon e Intel), Windows e Linux (.deb, .rpm ou AppImage), instalável também via brew install --cask opencode-desktop ou scoop. Para quem prefere uma janela dedicada em vez do terminal, é a mesma ferramenta com outra superfície — mas o rótulo beta está lá por um motivo, e vale tratá-lo como tal.

build, plan e o Tab: permissões como recurso de primeira classe

A decisão de design mais interessante do OpenCode não é técnica no sentido de arquitetura — é de ergonomia de segurança. A ferramenta vem com dois agentes embutidos, alternáveis com a tecla Tab:

• build — o padrão, com acesso total: edita arquivos, roda comandos, faz o trabalho de desenvolvimento.
• plan — modo somente leitura: nega edições de arquivo por padrão e pede permissão antes de executar qualquer comando bash. É o modo para explorar uma base de código desconhecida ou desenhar uma mudança antes de executá-la.

Parece um detalhe, mas muda o fluxo na prática. A maioria dos incidentes com agentes de código não vem de má intenção do modelo — vem de dar acesso de escrita a uma sessão que só precisava ler. Ter o modo restrito a um toque de tecla de distância, em vez de escondido em um arquivo de configuração, torna o comportamento seguro o comportamento barato. É o tipo de decisão que outros harnesses fazem por flags e políticas; aqui é parte da interface.

Completa o trio um subagente general, usado internamente para buscas complexas e tarefas de múltiplos passos, e que pode ser invocado explicitamente com @general na mensagem. É uma forma de delegar uma investigação longa sem poluir o contexto da conversa principal — padrão que vem se consolidando em todos os agentes maduros.

OpenCode contra Claude Code e Codex

A comparação honesta tem duas colunas.

A favor do OpenCode: é aberto de ponta a ponta (MIT, desenvolvimento público, 26,6 mil forks), não depende comercialmente de nenhum provedor de modelo, e a comunidade em volta — Discord ativo, README traduzido para mais de vinte idiomas, incluindo português do Brasil — indica adoção global real, não inflada por uma única bolha. Se o seu critério é auditabilidade e independência, ele vence por construção.

A favor dos concorrentes fechados: os harnesses dos laboratórios são co-desenvolvidos com os próprios modelos, e isso rende um ajuste fino que um projeto neutro precisa perseguir por fora. E há a questão do suporte: por trás do Claude Code existe a Anthropic respondendo por regressões; por trás do OpenCode existe a Anomaly e uma comunidade — arranjo que funciona muito bem até o dia em que você precisa de um SLA.

Um detalhe curioso do README mostra que o projeto já sofre o efeito colateral do próprio sucesso: há uma seção pedindo que projetos de terceiros que usem "opencode" no nome — como um hipotético opencode-dashboard — deixem claro no README que não são afiliados ao time oficial. Quando um projeto precisa policiar o próprio nome, é porque o ecossistema em volta dele cresceu além do controle. É bom sinal e alerta ao mesmo tempo: nem tudo com "opencode" no nome vem da mesma origem, e vale conferir antes de instalar.

As ressalvas

Nenhum número do parágrafo de abertura elimina as perguntas de sempre.

• 5,7 mil issues abertos. Em um projeto deste tamanho, volume alto de issues é esperado — mas é volume alto mesmo assim. Antes de adotar, vale filtrar os issues pelo seu sistema operacional e provedor de modelo e ver o que está quebrado para o seu caso.
• Ritmo de mudança. O push mais recente é do próprio dia da apuração, e o README recomenda remover versões anteriores a 0.1.x antes de instalar — sinal de que a base ainda muda de forma que quebra compatibilidade. O tap do brew da Anomaly é descrito como "sempre atualizado", enquanto a fórmula oficial "atualiza menos": em ambiente de trabalho, a versão que atualiza menos pode ser exatamente a que você quer.
• Desktop é beta. Está escrito no título da seção do README. Para trabalho que importa, o TUI é o caminho testado.
• Segurança operacional. Ser MIT e auditável não torna o agente inofensivo: o modo build tem acesso total ao que você der a ele. A recomendação padrão vale em dobro para qualquer agente com acesso a shell — avalie primeiro em um ambiente isolado (um container, uma VM, um repositório descartável) antes de apontá-lo para repositórios sensíveis ou com credenciais no ambiente. E use o modo plan como default em código que você ainda não conhece.

Leitura prática: quando faz sentido

Faz sentido se: você quer independência de provedor e a liberdade de trocar de modelo sem trocar de fluxo; trabalha em ambiente onde código fechado é um problema (auditoria, compliance, curiosidade legítima sobre o que a ferramenta faz); ou usa um sistema operacional/gerenciador de pacotes que os agentes dos laboratórios tratam como cidadão de segunda classe — a lista de canais de distribuição do OpenCode é imbatível nesse quesito.

Não faz sentido se: seu time já está profundamente investido no ecossistema de um provedor e satisfeito com o harness oficial — a troca custa hábito e integração sem ganho imediato; você precisa de suporte comercial formal com responsável nomeado; ou não tem como isolar o ambiente de teste e pretende dar acesso direto a repositórios de produção. Nesse último caso, o problema não é o OpenCode — é o processo.

O quadro geral: o OpenCode é a aposta mais forte até agora de que o harness de agentes de código pode ser infraestrutura neutra e aberta, em vez de canal de distribuição de modelo. As 203,9 mil estrelas em menos de um ano e meio dizem que muita gente quer que essa aposta dê certo. Os 5,7 mil issues abertos e o ritmo de mudança dizem que ela ainda está sendo construída em público — o que, para um projeto open source, é exatamente onde ela deveria estar.

Fontes

• GitHub — anomalyco/opencode (README)
• OpenCode — Documentação oficial

— Maxwell Diniz