Programa
Fundamentos do Negócio de IA
12 h
O OpenCode foi criado para executar uma tarefa de ponta a ponta. É um agente open source que conecta um modelo de IA ao seu repositório, terminal e ferramentas de desenvolvimento. Peça para corrigir um bug e ele encontra os arquivos relevantes, rascunha um plano, edita o código, roda testes e reage a erros. Um simples autocomplete não faz tudo isso sozinho.
Esse papel mais amplo chamou atenção. No momento em que escrevo, o repositório ativo do OpenCode tinha cerca de 189.000 estrelas no GitHub. Eu não trataria estrelas como prova de qualidade do código, mas elas mostram o quanto o projeto desperta interesse.
A realidade é menos arrumada. O OpenCode oferece uma escolha de modelos e pede que você gerencie essa escolha. Uma mudança de política de um provedor em janeiro de 2026 mostrou como essas opções podem mudar rápido. Vou abordar isso junto com o funcionamento do OpenCode e onde ele se encaixa.
Um aviso rápido sobre nomenclatura: ao buscar por OpenCode, você pode encontrar o repositório arquivado em Go opencode-ai/opencode. Esse projeto deixou de ser mantido em setembro de 2025. Vamos focar no projeto ativo em github.com/anomalyco/opencode, desenvolvido pela equipe por trás do framework Serverless Stack (SST).
O que é o OpenCode?
O OpenCode é um agente de codificação de IA open source, licenciado sob MIT. É agnóstico a modelos, ou seja, não fica preso a um único provedor. Os usuários podem ler o código-fonte e modificá-lo. Também é possível fazer self-host da ferramenta. O software é gratuito. A cobrança do modelo é separada, como vou detalhar em recursos.
O OpenCode não é um modelo de linguagem grande (LLM). O modelo escolhido lê os prompts e produz respostas. O OpenCode fornece as ferramentas de arquivo, acesso ao shell, histórico da sessão, regras de permissão e a interface em torno desse modelo. Acho essa distinção útil porque trocar o modelo não exige mudar o resto da ferramenta.
Ele é desenvolvido pela Anomaly, antes SST, e roda principalmente em TypeScript e Bun.
Repositórios do OpenCode arquivado e atual, lado a lado. Imagem do autor.
O OpenCode não está vinculado a uma única família de modelos. Por meio do registro Models.dev, ele se conecta a mais de 75 provedores, incluindo Anthropic, OpenAI, Google, DeepSeek, Groq e modelos locais via Ollama. Algumas contas de assinatura existentes também podem ser conectadas, como vou explicar na seção de recursos.
Sessão de terminal do OpenCode mostrando alterações em arquivos. Imagem do autor.
Embora o OpenCode tenha começado no terminal, hoje ele é distribuído como uma interface de terminal (TUI), um app desktop beta para macOS, Windows e Linux e extensões para editores como o VS Code. A versão estável mais recente no momento da escrita é a v1.18.8.
Por que o OpenCode foi criado
Como mencionei, o OpenCode dá suporte a modelos de vários provedores. Ele foi construído assim porque a qualidade e os preços dos modelos mudam, e uma ferramenta presa a um único provedor limita suas opções.
A documentação afirma que o OpenCode não é acoplado a nenhum provedor. O registro Models.dev citado acima fornece os detalhes e preços dos modelos que o OpenCode usa.
Essa escolha afeta mais do que a cobrança. Modelos diferentes têm limites de contexto, formatos de chamadas de ferramenta e tipos de entrada distintos. O OpenCode usa uma única interface para essas diferenças. Um desenvolvedor pode trocar o modelo selecionado no mesmo projeto sem mover a sessão para outra ferramenta de codificação.
A equipe também prefere ferramentas que priorizam o terminal e que o usuário possa inspecionar. As instruções do projeto ficam em um arquivo simples chamado AGENTS.md. Vou explicar como o OpenCode cria e usa esse arquivo mais adiante.
O projeto oficial cita três decisões de design. A primeira é o suporte a provedores, já coberto. A segunda mantém os principais controles no terminal. A terceira separa o cliente do servidor. Essa divisão vem a seguir.
Em janeiro de 2026, a Anthropic bloqueou ferramentas de terceiros de usarem assinaturas de consumo do Claude por canais não oficiais. O OpenCode então adicionou outras opções de assinatura e passou a usar seu próprio gateway. Os usuários ainda podiam se conectar por outros provedores.
Esse episódio explica por que a escolha de provedor recebe tanta atenção no OpenCode. Para ver como os usuários aproveitam essa escolha, o próximo passo é olhar uma sessão.
Como o OpenCode funciona
O OpenCode roda como um cliente e um servidor local. A TUI, o app desktop, as extensões de IDE e o SDK conversam com esse servidor via HTTP. O mesmo servidor permite anexar remotamente com opencode attach <url> e uso headless com opencode serve.
Dentro de uma sessão, o agente lê arquivos relevantes, pode rascunhar um plano, edita código e executa comandos quando necessário. Sua integração com o Language Server Protocol (LSP) então envia diagnósticos do compilador e do linter de volta ao modelo, para que ele responda a erros de tipo e sintaxe.
Por exemplo, uma tarefa pode começar com glob ou grep para localizar arquivos. O agente pode usar read para inspecioná-los e edit para alterar linhas selecionadas. Em seguida, pode usar bash para rodar um teste ou um comando de build. A saída vira parte da próxima solicitação ao modelo.
A separação entre Build e Plan é mais fácil de entender como uma chave de permissão. Build é o padrão e pode ler, escrever e executar comandos. Plan pede confirmação antes de editar arquivos ou rodar comandos bash. Pressionar Tab alterna entre eles.
As checagens de permissão se aplicam quando uma ferramenta é chamada. Um projeto pode permitir uma ferramenta, bloqueá-la ou perguntar ao usuário a cada vez. As regras também podem variar por padrão de comando. Um time pode permitir testes rotineiros, mas pedir confirmação antes de outros comandos de shell.
As sessões são armazenadas localmente em disco, no diretório de dados do OpenCode. O OpenCode compacta conversas longas automaticamente. Os comandos /undo e /redo navegam por snapshots de arquivos baseados em Git.
Principais recursos do OpenCode
O OpenCode agrupa suas funções em acesso a modelos, contexto do projeto, execução de tarefas e uso local. As seções abaixo explicam o que cada grupo muda durante uma sessão de codificação.
Suporte a múltiplos modelos
Como citado, o OpenCode obtém sua lista de provedores via Models.dev. Na prática, você pode conectar um serviço hospedado, uma plataforma de nuvem ou um endpoint compatível com OpenAI. GitHub Copilot e logins do ChatGPT Plus/Pro oferecem alternativas ao gerenciamento de uma chave de API separada.
Escolher o provedor não significa que todo modelo vai se comportar igual. Uso de ferramentas, limites de contexto, tempo de resposta e preço ainda dependem do modelo e do provedor selecionados. Chamadas a modelos hospedados também enviam o contexto de código exigido a esse provedor, sob as próprias regras de dados dele.
O OpenCode também oferece duas formas opcionais de acesso a modelos. OpenCode Zen é um gateway pré-pago por uso com uma lista selecionada de modelos. OpenCode Go é uma assinatura que custa US$ 5 no primeiro mês e depois US$ 10/mês, para modelos open-weight selecionados. O usuário ainda pode usar suas próprias chaves de API. Os preços podem mudar.
Aqui está a parte chata: uma ferramenta gratuita ainda pode gerar cobrança do provedor.
Trabalhando com contexto do repositório
Execute /init e o OpenCode gera um AGENTS.md com o resumo da estrutura e das convenções do projeto. As equipes podem commitar esse arquivo para que as sessões já comecem com instruções compartilhadas.
O arquivo pode incluir comandos de teste, nomes de pastas, regras de nomenclatura e observações sobre o projeto. Um AGENTS.md global pode guardar instruções usadas em vários projetos. O arquivo do projeto guarda as regras de um repositório.
As checagens do LSP descritas antes rodam após as edições. O contexto do repositório também inclui referências a arquivos: o símbolo @ puxa um arquivo selecionado para dentro do prompt.
Executando tarefas de codificação
Além dos agentes Build e Plan descritos, o OpenCode inclui subagentes para buscas em várias etapas, varredura da base de código e documentação externa. Agentes personalizados podem ter seu próprio modelo, prompt e permissões de ferramentas.
Cada subagente trabalha em uma sessão filha, então suas mensagens não incham a sessão principal do mesmo jeito. Um agente personalizado pode ser limitado a leitura de arquivos, usar um modelo de menor custo ou receber instruções para um tipo específico de tarefa.
Model Context Protocol (MCP) adiciona serviços externos. Eles são definidos em opencode.json, e as checagens de permissão já citadas também se aplicam às ferramentas adicionadas por eles.
Mudando do planejamento para alterações de código. Vídeo do autor.
Desenvolvimento local-first (e seus limites)
O termo "local-first" precisa de uma ressalva. Eu não o leria como uma promessa de que nada jamais sai da máquina. Como citado na seção de provedores, o OpenCode pode se conectar ao Ollama. Essa configuração mantém código e prompts na infraestrutura local. Modelos hospedados, /share e o OpenCode Zen enviam dados para fora da máquina local.
O uso local ainda depende do modelo. Modelos pequenos podem retornar chamadas de ferramenta inválidas ou perder relações entre arquivos. Um servidor local também precisa de memória suficiente para o modelo escolhido e de espaço de contexto suficiente para os arquivos enviados em cada requisição.
Seu sistema de permissões é um resguardo de fluxo de trabalho, não um sandbox de segurança. O modo servidor em rede deve usar OPENCODE_SERVER_PASSWORD e bindar para localhost. Um problema anterior de exposição sem autenticação foi corrigido, mas o modo servidor ainda não deve ser exposto publicamente sem autenticação.
Arquitetura do OpenCode
Como mencionei, o OpenCode separa seus clientes do servidor local. Essa divisão afeta a configuração e o estado armazenado. A API adiciona outra forma de usar o servidor.
Se você só pretende usar a TUI, pode ignorar os detalhes da API. O parágrafo de configuração ao final é a parte que você vai usar.
O servidor em TypeScript e Bun conversa com provedores de modelos e executa ferramentas. Ele também gerencia estado. Sua especificação OpenAPI 3.1 gera o @opencode-ai/sdk oficial. Scripts e clientes personalizados podem usar essa API documentada.
A API inclui sessões, mensagens, arquivos, provedores, ferramentas, agentes e configuração. É o mesmo servidor usado pelos próprios clientes do OpenCode. Um script pode criar uma sessão ou enviar uma mensagem sem tentar controlar a TUI.
Clientes do OpenCode conectados a um único servidor. Imagem do autor.
As interfaces listadas atuam como clientes: TUI, app desktop, extensão de IDE e opencode web. Todas conversam com o mesmo processo de servidor. Um dispositivo separado pode se anexar a uma sessão existente por esse processo.
Executar opencode serve inicia o servidor sem a TUI normal. Executar opencode web adiciona um cliente no navegador. Ambos os comandos precisam de autenticação se o servidor puder ser acessado de outro dispositivo.
A configuração fica no opencode.json ou opencode.jsonc do projeto, com um fallback global em ~/.config/opencode/opencode.json. Ele controla modelos, permissões, servidores MCP e agentes personalizados. Como citado na seção de fluxo de trabalho, o histórico da sessão e os logs de ferramentas permanecem em arquivos locais, a menos que o usuário os compartilhe.
Fluxos de trabalho comuns no OpenCode
As mesmas partes do OpenCode podem ser usadas em várias tarefas comuns de software. Os exemplos abaixo mostram onde a revisão humana ainda é essencial em cada uma.
Construindo novas funcionalidades
Usando o processo Plan-to-Build descrito, o desenvolvedor pode solicitar uma feature e revisar os passos propostos antes de qualquer edição. Pressionar Tab move a tarefa para o modo Build para mudanças de código e testes.
O plano pode ser revisado antes de qualquer alteração de arquivo. Eu usaria essa revisão para ajustar o escopo, nomear arquivos que não devem mudar ou adicionar requisitos de teste.
Refatorando código existente
O mesmo processo Plan-to-Build funciona para refatoração. O modo Plan pode identificar dependências e pontos de chamada antes de o modo Build aplicar as edições. Se o resultado ficar errado, /undo restaura o snapshot anterior. O usuário ainda precisa revisar o diff, pois testes passando não confirmam que toda a interface pública permaneceu igual.
Depurando aplicações
Para debugging, o OpenCode pode combinar um stack trace com informações de tipo vindas do language server. Ele pode propor uma alteração, repetir os passos que causaram o erro e checar o resultado. Sem passos claros de reprodução, pode apenas confirmar que o código compila ou que os testes existentes passam.
Escrevendo testes
Como vimos, o modo Build pode editar arquivos e executar comandos. Para escrita de testes, isso significa criar um teste, ler o resultado e fazer outra mudança. Uma suíte de testes completa dá mais feedback, mas leva mais tempo.
A qualidade dos testes ainda precisa de revisão humana. Um teste gerado pode repetir a implementação em vez de verificar o comportamento do qual os usuários dependem.
Entendendo bases de código grandes
A seção do repositório explicou como /init cria notas do projeto. Depois disso, uma pergunta como "Como a autenticação funciona aqui?" pode guiar a busca. O subagente @general pode procurar em várias partes do repositório.
Perguntas específicas costumam gerar resultados mais claros do que pedidos para explicar o repositório inteiro. Referências a arquivos com @ podem afunilar ainda mais a busca.
OpenCode vs. outros agentes de codificação com IA
Essas ferramentas diferem em licença, suporte a modelos, interface e cobrança. Eu as comparo nesses pontos em vez de tratar uma delas como escolha padrão.
OpenCode vs. Claude Code
Temos um artigo separado comparando OpenCode e Claude Code com mais detalhes. O Claude Code é proprietário e usa o modelo e o sistema de contas da Anthropic. O OpenCode usa licença MIT e pede ao usuário para selecionar o provedor. Ele também dá acesso ao código-fonte e à configuração. Como citado no histórico, assinaturas de consumo do Claude não funcionam mais via OpenCode, então o uso do Claude requer uma chave de API medida da Anthropic.
Ambas as ferramentas leem arquivos, fazem mudanças, rodam comandos e usam servidores MCP. O acesso ao modelo é a principal diferença: o Claude Code fica no ecossistema da Anthropic descrito acima, enquanto o OpenCode pode se conectar a outros provedores ou a um endpoint local.
OpenCode vs. Cursor
Cursor é um IDE baseado em VS Code que também oferece agentes via CLI e na nuvem. Seu fluxo principal mantém sugestões, mudanças de arquivo e ações do agente dentro do editor. O OpenCode usa as interfaces de terminal, desktop e editor citadas. O Cursor tem planos pagos por assinatura. O software do OpenCode é gratuito, mas você pode pagar ao provedor do modelo pelos tokens. As principais diferenças são a interface de trabalho, a escolha de modelos e a forma de cobrança.
O Cursor também inclui completion inline enquanto o desenvolvedor digita. O OpenCode foca em tarefas entregues ao agente e não substitui esse tipo de completion. Alguns desenvolvedores podem usar ambos os tipos de ferramenta para trabalhos diferentes.
OpenCode vs. Cline
Cline tem como núcleo um agente open source, BYOK, com interfaces para VS Code e CLI. Ele também possui um cliente para JetBrains, embora esse cliente não seja open source no momento da escrita. Cline e OpenCode suportam MCP e permitem definir regras de aprovação. O Cline posiciona seus controles do editor em uma barra lateral. O OpenCode usa sessões de terminal que podem rodar separadas do editor. A escolha depende principalmente de onde o desenvolvedor prefere revisar e aprovar mudanças.
O Cline usa licença Apache 2.0. O OpenCode usa a licença MIT citada. Ambos permitem revisar e alterar o código-fonte, mas suas interfaces e arquivos de projeto são diferentes.
Aider e Codex CLI também são agentes de codificação baseados em terminal. O OpenCode cobre terminal, desktop e IDE no mesmo projeto e dá suporte a modelos de vários provedores.
Instalação e primeiros passos com o OpenCode
O script oficial de instalação funciona na maioria dos sistemas tipo Unix. Ele oferece uma forma de instalar a ferramenta de linha de comando:
O comando baixa o binário do OpenCode e o adiciona ao ambiente do usuário. Um gerenciador de pacotes pode ser melhor quando as atualizações são gerenciadas junto com o resto do sistema.
curl -fsSL https://opencode.ai/install | bashOpções com gerenciadores de pacotes incluem npm i -g opencode-ai@latest, brew install anomalyco/tap/opencode no macOS e Linux, e scoop install opencode ou choco install opencode no Windows. Há um app desktop para macOS, Windows e Linux. No Windows, a documentação do OpenCode recomenda WSL, pois algumas funções de sistema de arquivos e shell funcionam melhor lá.
A instalação não inclui acesso a modelos. A primeira sessão ainda precisa de um dos métodos de acesso descritos na seção de múltiplos modelos.
Instalando o OpenCode antes de criar instruções do projeto. Vídeo do autor.
O OpenCode é realmente gratuito para usar?
Posso usar modelos Claude dentro do OpenCode?
O OpenCode funciona sem conexão com a internet?
O repositório arquivado opencode-ai/opencode é o mesmo projeto?
Como o OpenCode lida com a privacidade do meu código-fonte?
Tópicos