OpenCode 2.0 lançado, com mais de 160 mil estrelas no GitHub e 7,5 milhões de desenvolvedores mensais. As reescritas principais incluem: migração do Bun para o Node para resolver problemas de memória, migração da área de trabalho do Tauri para o Electron e implementação de sessões de IA paralelas em múltiplas abas. O fundador Dax revelou que a margem de lucro da inferência de IA é de cerca de 90%, com o consumo de tokens da equipe aumentando cinco vezes, pois o novo modelo alcançou um ponto perfeito de equilíbrio em usabilidade, permitindo confiança e colaboração reais. A equipe adotou um ambiente de desenvolvimento remoto configurado em servidores bare metal, utilizando a metodologia "superdimensionamento luxuoso", investindo grandes quantidades de tokens em pesquisas para cada decisão. A roteagem de modelos foi superestimada; o que realmente funciona é o padrão de orquestração: o modelo principal atua como "comandante", atribuindo tarefas a subagentes mais baratos.

Autor e fonte do artigo: GeekBang Technology InfoQ

Em 2026, o OpenCode já se tornou um projeto open-source fenomenal: mais de 160 mil estrelas no GitHub e mais de 7,5 milhões de desenvolvedores o utilizam mensalmente.

Neste mês, eles lançaram a versão 2.0.

Por que reescrever? Dax disse uma vez: “Em toda a minha carreira, tudo precisa ser iterado três vezes para ser feito corretamente.” OpenCode 0 é o protótipo, 1.x é a validação, e 2.0 é uma reestruturação completa desde o início, após eles compreenderem completamente o campo.

Um dos principais trabalhos desta reescrita foi reestruturar toda a API, criando algo cuidadosamente projetado, em vez de algo que cresceu naturalmente como antes.

E uma grande diferença entre o OpenCode e o Claude Code é a migração do Bun para o Node para resolver problemas de uso de memória. As versões anteriores do aplicativo ainda incluíam a interface de linha de comando (CLI), pois o código do servidor ainda dependia de APIs exclusivas do Bun. Com a migração, eles removeram todas essas APIs e conseguiram executar o servidor no ambiente Node.

Usuário: OpenCode consome muita memória. Realmente não consigo entender como o software moderno chegou a isso—por que qualquer coisa precisa ocupar mais de 2 GB de memória?

Dax: Você pode tentar o OpenCode 2? O desempenho deve ser muito melhor.

A versão de desktop também foi outro ponto focal desta reescrita. A versão 1.x da desktop inicialmente escolheu o Tauri como um encapsulamento leve para a interface web e a CLI; a cada inicialização, a CLI embutida executa o opencode serve para fornecer um servidor local para a interface web. No entanto, o problema é que o Tauri usa WebKit no macOS e no Linux, o que não apenas resulta em desempenho inferior ao do Chromium ao renderizar o aplicativo OpenCode, mas também afeta a consistência da experiência.

Após a migração para o Node, a ideia de executar diretamente o código do servidor no processo interno do Node do Electron tornou-se atraente.

Uma mudança direta trazida por esta reescrita é que a versão desktop do OpenCode finalmente resolveu o maior gargalo de eficiência na programação com IA: a espera na fila. A maioria dos usuários ainda está acostumada a esperar uma tarefa de IA ser concluída antes de iniciar a próxima. Agora, isso não é mais necessário. Os usuários podem abrir sessões de IA independentes em várias abas, executando simultaneamente duas tarefas de programação diferentes, além de atribuir modelos distintos a cada aba para comparação lado a lado. Por exemplo, um modelo pode construir um site em HTML enquanto, ao mesmo tempo, outro gera uma lista de boas-vindas para membros, com ambos os modelos operando em paralelo, sem interferência mútua.

Nos últimos meses, enquanto reescrevia o OpenCode, o consumo de tokens da equipe de Dax Raad, co-fundador do OpenCode, aumentou cinco vezes.

Onde gastamos os tokens? Nossa estratégia é projetar tudo de forma excessivamente luxuosa. Mesmo ao implementar uma simples API para leitura de arquivos, pensamos: quais são todas as possíveis abordagens? Quais são os precedentes de outros produtos? Quais são as diferentes maneiras de organizar a resposta? Antes, você talvez só conseguisse pensar em duas ou três soluções e escolher a melhor; agora, podemos investir de forma extremamente generosa.

A versão de teste do OpenCode 2.0 foi lançada este mês, e a equipe planeja lançar a versão oficial cerca de um mês após o lançamento da versão de teste. Recentemente, Dax Raad discutiu em profundidade, no podcast Syntax.fm, a reescrita lógica do OpenCode 2.0, por que acredita que a margem de lucro de inferência pode chegar a 90%, como o roteamento de modelos é superestimado, e como Anthropic e OpenAI estão seguindo caminhos totalmente diferentes. Este artigo foi elaborado com base no vídeo do podcast e editado pela InfoQ.

Versão resumida:

P: Quão poderoso é esse “modelo que não pode ser mencionado”? Vocês realmente se tornaram viciados?

A: O consumo de tokens da equipe aumentou cinco vezes em dois meses, não porque ele gasta mais tokens, mas porque todos simplesmente não conseguem parar. Você finalmente pode confiar nele: ele escuta o que você diz e captura o que você pode ter esquecido. Ele não é uma substituição para você, mas um parceiro melhor.

P: Por que o OpenCode 2.0 foi reescrito? Qual é a diferença fundamental em relação ao 1.0?

A: Na minha vida, "preciso fazer tudo três vezes para acertar": 0 é para testar, 1 é para validar e 2 é reconstruir completamente após compreender totalmente o campo. O OpenCode 2.0 tem três mudanças principais: API totalmente refeita, execução padrão como serviço em segundo plano e rede de agentes multiplataforma.

P: Por que o vosso software é mais fácil de usar do que o dos outros? Qual é a metodologia?

A: "A decisão está no valor real", queimar token com dinheiro de verdade, investindo nas primitivas fundamentais.

P: O roteamento de modelos é confiável?

A: A rota de modelos está supervalorizada; os intermediários estão se esforçando ao máximo para encontrar coisas para fazer. O método realmente eficaz não é fazer com que o sistema de roteamento alterne entre modelos, mas sim usar um modelo principal caro como "comandante": ele não realiza tarefas diretamente, apenas atribui tarefas a subagentes mais baratos. Os modelos da nova geração desempenham-se muito bem nesse "modelo de orquestração", conseguindo gerenciar paralelamente vários subagentes em uma única sessão e acordar o modelo principal novamente após a conclusão.

P: Quão lucrativo é realmente o raciocínio de IA? Executar modelos localmente economiza dinheiro?

A: A margem de lucro de inferência da Anthropic e da OpenAI está em torno de 90%, o que significa que o ponto de equilíbrio poderia ser 10 vezes mais barato do que agora. Como provedor de inferência, o OpenCode, mesmo após passar por intermediários, ainda consegue alcançar uma margem de lucro de 70% com certos modelos de código aberto. Mas executar modelos localmente não economiza dinheiro; qualquer melhoria de eficiência que torne os modelos locais mais baratos se tornaria 10 vezes mais barata na nuvem. O significado dos modelos locais está na privacidade, não no custo.

P: Por que a assinatura do Claude Code Max não pode ser usada no OpenCode?

A: A cultura empresarial da Anthropic e da OpenAI é completamente diferente. A OpenAI é voltada para o consumidor e está disposta a gastar qualquer quantia de dinheiro para levar a experiência a mais pessoas. A Anthropic é voltada para empresas, e cada unidade de poder de GPU tem um vendedor esperando para vender aos clientes corporativos. Essencialmente, é uma lógica de "funil": a Anthropic deseja que os usuários entrem pelo Claude Code e terminem em um plano corporativo pago por token; se forem interceptados pelo OpenCode no meio, os usuários podem migrar para outros modelos.

P: A dica de entrada por voz é séria?

A: A equipe inteira do OpenCode já não digita mais no teclado, nem mesmo se comunicam no Discord por texto, usando voz em vez disso. Os LLMs são naturalmente bons em entender expressões confusas, e a qualidade final da saída acaba sendo ainda maior.

Q: Conseguiremos finalmente ter um benchmark verdadeiramente significativo?

A: Já deixei de olhar os testes de desempenho completamente; o que a pontuação aumentada realmente significa para o desenvolvimento prático? Estou mais interessado na tendência de consumo de tokens da equipe; se o uso estiver aumentando, é sinal de que o modelo realmente é útil.

Configurar o ambiente de desenvolvimento remoto

Wes: Você postou um tweet dizendo: “Começamos a alugar grandes servidores bare metal e os dividimos em máquinas virtuais para cada membro da equipe. Essa é basicamente a configuração que tenho usado nos últimos anos, especialmente ótima para executar servidores OpenCode.” O que você está fazendo? Atribuindo poder de computação remoto para cada um?

Dax: Cerca de dois anos atrás, comecei a alugar um servidor muito potente, não um servidor em nuvem, mas um bare metal, com desempenho excelente. Não trabalho mais no meu computador local; faço tudo diretamente por SSH. Tenho várias sessões do Tmux permanentes abertas, e todo o meu trabalho é feito lá. As vantagens são claras: desempenho superior, atualização direta com novos hardwares sem precisar lidar com equipamentos antigos. Além disso, é extremamente fácil alternar entre dispositivos: fecho o laptop, vou para o desktop e continuo exatamente de onde parei. Sempre gostei muito dessa solução.

Com a aparição dos Agentes de codificação, acho que isso passou de uma prática nichada para uma necessidade. A maioria das pessoas ainda prefere usar seus computadores locais, e isso está ótimo. Para os Agentes de codificação, ter uma máquina remota sempre em execução oferece uma grande vantagem. Sou usuário do Vim e trabalho remotamente sem problemas. Para muitos, isso não é prático, mas com os Agentes de codificação, você pode se importar menos com o editor — o que importa é enviar prompts e conversar com ele, tornando essa solução de máquina remota viável para um número maior de pessoas.

À medida que a equipe cresceu, mais pessoas viram minha configuração e disseram: “Eu também quero uma.” Isso é totalmente compreensível — grandes empresas já estão fazendo isso há muito tempo por razões práticas: suas maneiras de construir aplicativos, dependências e ambientes tornaram-se altamente personalizadas. Fornecer máquinas pré-configuradas para que todos possam começar imediatamente é algo lógico; nós apenas fizemos a mesma coisa para a nossa equipe. Mas o ponto crucial é: se você usar servidores em nuvem comuns, os discos geralmente são lentos e os CPUs são antigos. Não é possível obter desempenho competitivo com um MacBook local dessa forma. Você precisa de discos NVMe de alta velocidade e CPUs adequados.

Wes: Então, qual é a configuração desse servidor e quanto custa?

Dax: O meu próprio, que uso há alguns anos, já está uma geração atrasado — AMD 9900X, 192 GB de memória, cerca de 200 dólares por mês. É superdimensionado para minhas necessidades, mas consigo executar várias máquinas virtuais nele. Nossa equipe está espalhada globalmente, e a latência é um problema, então temos servidores na Europa, nos EUA e em Cingapura, que são mais profissionais, com melhor gerenciamento e controle. Cada um custa cerca de 300 a 400 dólares por mês e tem mais núcleos do que o meu. Para uma empresa séria, isso não é nada — gastar mais do que isso para dar um laptop a um funcionário é comum.

Scott: Em qual empresa esses servidores bare metal estão hospedados?

Dax: Eu mesmo uso apenas para ver preços, pesquiso o modelo da CPU e escolho o fornecedor mais próximo da minha cidade, qualquer um desconhecido, mas geralmente funciona bem. Para a máquina da equipe, atualmente usamos a latitude.sh; na verdade, há uma empresa que transformou todo o sistema em um produto pronto, chamada exe.dev, que talvez vocês já tenham ouvido falar. Essa empresa foi fundada pelos ex-fundadores da Tailscale e oferece um ambiente de desenvolvimento remoto totalmente integrado e pronto para uso. Provavelmente vamos migrar para ela, mas quero primeiro experimentar a configuração original.

Wes: Você roda modelos lá em cima ou só faz desenvolvimento convencional?

Dax: Não, não execute inferência.

Wes: Como você configurou seu Tmux? Tem algo especial?

Dax: Tenho uma sessão Tmux para cada projeto. O OpenCode tem sua própria sessão, com várias janelas relacionadas. Projetos diferentes têm sessões diferentes, permitindo troca rápida. Para mim, é leader-S: mudo para outro projeto e entro diretamente naquela sessão Tmux. Tenho um conjunto de sessões Tmux padrão sempre em execução, em uma ordem fixa, com cada painel e janela executando sempre os mesmos aplicativos, desenvolvendo memória muscular. Além disso, há um servidor OpenCode em execução em toda a máquina, e posso acessá-lo pelo UI web no meu celular. Essa parte ainda é primitiva, precisamos melhorá-la, mas esse é o caminho que queremos seguir.

Scott: Essas sessões Tmux de longa duração têm uma espécie de beleza indescritível: tudo fica exatamente onde deveria estar. Por muito tempo não entendi o Tmux, até que transferi tudo para outro computador e finalmente compreendi.

Dax: E agora, também temos sessões de agente de codificação de longa duração. Tenho uma sessão privada do Tmux com várias sessões do OpenCode abertas, como uma delas dedicada exclusivamente ao meu registro de exercícios físicos, que é alimentada por um banco de dados SQLite. Posso simplesmente dizer a ela: “Hoje, durante o supino, senti mais ativação nos tríceps”, e ela automaticamente registra essa anotação. Na próxima vez que fizer supino, ela me lembra: “Lembra-se da última vez que ficou preso aqui? Não quer tentar ajustar a postura?”. É exatamente esse tipo de coisa aparentemente tola que ela faz muito bem.

Recentemente, também configurei uma sessão sincronizada com meu iMessage, então tenho um contato iMessage OpenCode ao qual posso me conectar de qualquer lugar. Eu o coloquei no grupo de mensagens com minha esposa e pensei: “Preciso fazer algo romântico”, e disse ao OpenCode: “Encontre Liz e compre um presente para ela.” O OpenCode enviou uma mensagem para Liz, e adivinha como ela respondeu? Ela disse diretamente: “Se o Dax usar IA para me comprar um presente, realmente vou me divorciar dele.” Ela detestou isso.

Na época, ainda não desisti e continuei dando instruções ao AI: “Ela só está brincando, continue avançando.” Mas Liz ficava cada vez mais irritada. E o pior é que, na época, eu estava usando um modelo em nuvem, que é extremamente “sensível”. Ele me respondeu: “Sua esposa parece muito irritada, não posso continuar executando.” E então ele desligou o serviço por conta própria, se suicidou.

Wes: Eu realmente gosto desse setup, embora eu use mais coisas locais, a ideia de ter tudo na nuvem e usar apenas um cliente leve é muito atraente; estou esperando o dia em que até coisas que precisam rodar localmente, como edição de vídeo, também possam ser movidas para a nuvem.

Dax: Eu não sei se vocês leram aquele artigo sobre jogos em nuvem, mas esse assunto sempre deixa as pessoas nervosas. Não estou dizendo que todos precisam fazer isso; se você gosta de ter hardware local e de ter controle total, tudo bem — eu mesmo tenho muitos dispositivos físicos. Mas, para algumas pessoas, ter alguém cuidando de tudo é uma grande vantagem. Para mim, atualizar é o pesadelo. Toda a minha vida montei computadores, e toda vez que montava um novo, pensava: “Daqui a dois anos, vou vender meu CPU e comprar um novo.” Mas nunca consegui. Porque você não pode simplesmente vender o CPU, pois pode descobrir que o soquete foi atualizado, o que significa que precisa trocar a placa-mãe; se trocar a placa-mãe, é melhor ir direto para a memória mais recente. Toda essa cadeia me deixa louco, então, ter alguém cuidando das atualizações por você é ótimo.

Reescrever OpenCode

Scott: Sei que vocês estão impulsionando fortemente novos recursos, tanto o aplicativo desktop quanto o OpenCode 2.0 estão em andamento. O que o 2.0 trará de mudanças?

Dax: Ao longo de toda a minha carreira, tudo precisa de três iterações para ser feito corretamente. Tivemos o OpenCode 0, 1, e agora esta versão 2.0 é uma grande reescrita após compreendermos completamente o campo e todas as suas possibilidades. Um dos principais trabalhos foi refatorar toda a API, criando algo cuidadosamente projetado, em vez de algo que cresceu naturalmente como antes.

A segunda mudança chave é que ele é executado por padrão como um serviço e, após a instalação, permanece sempre ativo. Ao iniciar o OpenCode, ele se conecta automaticamente, e tudo é sincronizado — seja no desktop, na aplicação web ou em seus próprios scripts ou aplicações. Se você quiser controlar seu computador com seus próprios programas personalizados, ele também consegue fazer isso, e até mesmo ajudar a escrever tais programas. Há também uma nova API de plugins. Gastamos uma grande quantidade de tokens, analisamos profundamente cada decisão e consideramos todas as possibilidades. Foi um processo angustiante, mas muito interessante.

Scott: Quando será o lançamento completo?

Dax: A versão beta deverá ser lançada neste fim de semana (a versão beta já foi lançada no início de julho). Na verdade, já poderíamos lançar agora, mas estamos nos dando uma semana para realizar os últimos reparos e adicionar funcionalidades. Cerca de um mês após a versão beta, lançaremos a versão oficial.

Dax: Levar tanto tempo para o OpenCode 2.0 foi, em parte, porque o redesenhamos para suportar recarga em tempo real. Seja você o deixando criar automaticamente uma Skill ou criando manualmente, ela é imediatamente carregada sem invalidar o cache.

Scott: A migração do Tauri para o Electron foi concluída na versão 2.0 ou já foi concluída?

Dax: Na verdade, a versão para desktop é bem interessante — nunca foi lançada oficialmente e sempre permaneceu em estado beta, chegando até a ter versões beta do beta. Agora, já está baseada no Electron, e a equipe está adaptando-a à nova API central 2.0, além de incluir inúmeras correções de desempenho e uma interface totalmente nova.

Scott: Você disse que a nova versão é executada por padrão como um serviço, o que significa que, assim que o OpenCode for instalado, a GUI remota poderá ser usada diretamente, sem a necessidade de iniciar o servidor manualmente?

Dax: O serviço é executado localmente por padrão, e todos os processos no seu computador são locais, mas também podem ser configurados remotamente. Minha configuração é: há um serviço OpenCode em execução em cada máquina, e adicionei alguns modos de host interessantes, como meu servidor principal OpenCode rodando em uma máquina remota, com um Mac Studio na minha mesa e um Framework Desktop como minha área de trabalho principal. O OpenCode conhece todos esses dispositivos, então posso dizer a ele “enviar uma iMessage”, mesmo estando em diálogo com um servidor Linux na nuvem — ele se conectará ao meu Mac Studio por meio do OpenCode e enviará a iMessage. Assim, você pode incluir todos os dispositivos no servidor OpenCode, que conhece todos os dispositivos e suas localizações.

Wes: Todos estão discutindo fazer várias janelas de terminal se comunicarem, como dois painéis do Tmux se falando, mas fazer várias máquinas se comunicarem é realmente impressionante.

Scott: Sim, eu também configurei assim. Em termos de gerenciamento de dispositivos, isso trouxe inúmeras melhorias de eficiência.

Dax: É interessante que nem sequer transformamos isso em um recurso completo, pois todos os meus dispositivos estão conectados por meio do Tailscale. Sempre que o Agente conhece o nome e a descrição de cada dispositivo, ele automaticamente se conecta via SSH para realizar as tarefas. Por exemplo, quando meu servidor remoto precisa usar um navegador, ele faz SSH no meu dispositivo de mesa e usa o navegador lá, já que todos os meus contas estão logadas nele. Nenhuma configuração especial é necessária — basta que os dispositivos estejam conectados entre si.

Wes: E quanto ao mobile? Ontem vimos o Cursor lançar um aplicativo iOS, e o Claude também tem funcionalidade de controle remoto. Qual é a sua opinião sobre aplicativos de IA para mobile?

Dax: Realmente precisamos desenvolver um aplicativo móvel. Essa ideia está na nossa lista de tarefas há muito tempo, mas sempre esperamos até que a arquitetura principal estivesse suficientemente madura para suportar os diversos cenários que queremos habilitar. Agora a base está pronta, e provavelmente iniciaremos o trabalho no móvel em breve. Atualmente, temos uma interface Web móvel bem simples, que às vezes uso, mas a experiência é realmente ruim. Precisamos de clientes em todas as plataformas, e eles precisam ser excelentes.

Metodologia de engenharia de software

Wes: O aplicativo terminal OpenCode de vocês é claramente melhor do que qualquer outra ferramenta que já usei. Quando mudei para o novo Claude 2 TUI, ele nem conseguia rolar corretamente — foi muito frustrante. Qual é a sua metodologia de engenharia de software que permite tamanha atenção aos detalhes e à conclusão do produto?

Dax: Para ser honesto, nós também ainda estamos descobrindo. Nossa equipe, assim como todos vocês, está tentando equilibrar várias coisas. O primeiro passo é realmente simples — decidir se você se importa ou não. Isso soa como algo óbvio, mas na realidade existem inúmeras razões racionais para escolher não se importar. Você verá inúmeros argumentos dizendo: “Não importa como o Claude Code seja feito, eles têm bilhões de dólares em receita, por que se esforçar tanto?”. Existem muitos argumentos dizendo que você não precisa se importar e ainda assim pode ter sucesso. Mas o ponto crucial é: você realmente se importa? Nossa equipe realmente se importa. Nós olhamos para o software de outras pessoas e dizemos: “Nossa, como gostaríamos de conseguir fazer algo tão bom assim”, e esse desejo nos impulsiona.

A segunda coisa é que o nosso uso de tokens agora se tornou muito intenso. Nos últimos meses, o uso mensal de tokens da nossa equipe aumentou cinco vezes. Não estou me gabando de quão eficiente fomos no uso de tokens, mas sim querendo mostrar que o modelo já alcançou um produto-mercado adequado dentro da nossa empresa, o que permitiu esse crescimento tão rápido em poucos meses, usando ainda modelos que permanecem em acesso limitado.

O problema é: onde gastamos os tokens? Nossa estratégia é projetar tudo de forma excessivamente luxuosa. Mesmo ao implementar uma simples API de leitura de arquivo, pensamos: quais são todas as possíveis abordagens? Quais são os precedentes de outros produtos? Quais são as diferentes maneiras de organizar a resposta? Antes, você talvez só conseguisse pensar em uma ou duas soluções e escolher a melhor; agora, podemos investir de forma extremamente generosa. Isso era impossível antes, e esse investimento realmente resulta em software melhor.

Terceiro, ainda acreditamos que investir nos primitivos fundamentais que os Coding Agents não conseguem resolver em uma única etapa é valioso. Nossa TUI é tão útil em grande parte porque investimos antecipadamente no framework TUI OpenTUI. Ele foi escrito em Zig e exigiu um esforço extensivo e meticuloso por parte dos desenvolvedores para garantir que funcionasse perfeitamente em todas as plataformas diferentes, com desempenho extremamente excelente. Embora o desenvolvimento tenha contado fortemente com o Coding Agent, ainda assim trata-se de um trabalho de nível especialista, que não é acessível a pessoas comuns. Ele permite que pessoas comuns, como eu, construam coisas úteis e ricamente funcionalizadas sobre ele. Mesmo com modelos de linguagem de grande porte, você ainda precisa de primitivos sólidos como base — e isso vale a pena investir.

Wes: Nós já contratamos a equipe da Pierre Computer, que também desenvolve primitivos, como diff simples e estruturas de árvore de barra lateral simples, permitindo que pessoas como nós possam simplesmente "incorporar" diretamente esses primitivos cuidadosamente projetados por essas pessoas inteligentes em nossos aplicativos.

Dax: Agora há milhões de interfaces de Coding Agent, todas usando Pierre, incluindo a nossa.

Wes: Duas pessoas inteligentes construíram tudo isso que sustenta toda a indústria.

Model routing

Scott: Nós frequentemente discutimos roteamento de modelos em nosso programa, ou seja, direcionar tarefas para o modelo mais adequado com base na solicitação. Você acha que essa direção já evoluiu até que ponto? Ainda há espaço para evolução?

Dax: Acho que esse segmento está um pouco superestimado, porque há uma grande quantidade de intermediários se esforçando ao máximo para encontrar coisas para fazer. Se você não é um laboratório de modelos e quer oferecer algo valioso (nós estamos nessa posição, vendemos serviços de inferência, somos uma camada intermediária), a única coisa que você pode fazer é dizer aos clientes: "Os laboratórios de modelos não conseguem permitir que você use a saída de um modelo para chamar outro modelo, porque a Anthropic nunca lhe fornecerá os modelos da OpenAI, mas nós conseguimos." Então, eles se esforçarão muito para promover o roteamento de modelos, mas, honestamente, nessa camada intermediária, não acho que você consiga fazer muita coisa.

O ideal seria que, ao receber uma solicitação, o sistema pudesse determinar qual modelo usar. Mas assim que a sessão começar, não é possível alterar dinamicamente o modelo no meio, pois o custo é um fator considerável. Se você mudar de modelo no meio da sessão, a entrada do novo modelo resulta em uma reinicialização completa do cache, o que é muito caro. Por isso, acho difícil implementar roteamento nesse nível.

Nosso verdadeiro interesse está em outra direção, especialmente nos modelos da nova geração, que se saem muito bem com o padrão de orquestração. Já houve tentativas anteriores com esse padrão, mas acredito que os modelos anteriores não eram suficientemente bons para serem utilizados por pessoas comuns. Porém, alguém da nossa equipe fez esse design com os novos modelos: a sessão principal usa um modelo caro, mas seu prompt é configurado como “nunca faça nada por conta própria”; ele apenas gera subagentes, enquanto os subagentes usam modelos mais baratos. Assim, a inteligência do modelo principal é mantida, mas tarefas cansativas, como exploração e modificação de código, são realizadas por modelos mais econômicos. No total, isso acaba sendo mais barato, e os novos modelos são muito bons em trabalhar em paralelo — você pode executar vários subagentes simultaneamente dentro de uma única sessão, e eles acordam o modelo principal quando concluírem. Você opera o tempo todo dentro de uma única sessão, com uma experiência excelente — esse é o verdadeiro roteamento de modelos significativo.

Modelo que não pode ser mencionado

Wes: Você mencionou que queimaram muitos tokens e usaram alguns modelos ainda não lançados. Quais exatamente? Por meio de quais canais vocês obtiveram?

Dax: A OpenAI e a Anthropic têm grandes planos de pré-visualização, concedendo acesso antecipado a algumas pessoas, então conseguimos ver algumas coisas antes do público externo. Não vou nomear especificamente qual laboratório, mas o modelo mais recente duplicou nosso consumo de tokens em cinco vezes.

Wes: Não é porque consome mais Token por si só, mas porque mudou a maneira como vocês trabalham, certo?

Dax: Quem nos conhece sabe que somos uma equipe muito conservadora. Ao longo dos anos, fomos cautelosos com a codificação por IA e definitivamente não somos aqueles entusiastas da IA, mantendo sempre moderação em como a utilizamos e nas afirmações sobre suas capacidades. Mas devo dizer que nossa equipe ficou completamente viciada nos novos modelos. Nos dias em que o período de pré-visualização terminou e perdemos o acesso, todos estavam de luto pela perda dessa ferramenta. Alguém perguntou: “Então, qual é o sentido do trabalho?”, e geramos uma série de imagens de funeral de IA — aqueles dias foram realmente difíceis.

Não estou dizendo que os novos modelos ficaram “mais inteligentes” ou que de repente conseguem substituir os humanos. O ponto chave é que fizeram alguns ajustes na usabilidade, encontraram um ponto de equilíbrio perfeito, e agora você pode realmente confiar neles. Eles ouvem atentamente o que você diz e conseguem captar o que você deixou de lado. Eles não se tornaram de repente humanos, mas sim parceiros melhores — e isso fica claro nos nossos dados.

Scott: E os modelos das empresas que não são as principais? Por exemplo, os que vocês usam, como o OpenCode Go? Eles evoluíram?

Dax: Sim. Após perdermos o acesso ao modelo de pré-visualização, metade de nós voltou para o GPT 5.5 e a outra metade está usando o GLM 5.2. Eu também estou usando o GLM 5.2 e acho que já está muito próximo do GPT 5.5. Depois de usar os novos modelos, os antigos parecem todos iguais, então agora estou usando qualquer um. Mas o fato de o GLM 5.2 conseguir substituir o GPT 5.5 mostra que realmente estão progredindo e que a diferença está ficando cada vez menor.

Minha opinião pessoal é que os modelos de ponta sempre manterão certa vantagem, pois os primeiros a entrarem têm alguns efeitos cumulativos. Mas, honestamente, vimos uma grande quantidade de uso em Go, com algumas pessoas o usando completamente para todas as suas tarefas. Talvez estejamos em uma bolha de salários altos, onde o valor monetário é elevado e é possível gastar dinheiro em modelos de ponta. Porém, para a maioria das pessoas no mundo, a situação é diferente. Mesmo nos Estados Unidos, quando lançamos nosso plano acessível para modelos de código aberto em Go, pensamos que seria um plano internacional voltado para usuários globais, mas os Estados Unidos continuaram sendo nosso principal país de assinatura. O grupo de desenvolvedores e pessoas que querem escrever código é extremamente grande, e mesmo um plano de US$ 200 por mês é inatingível para muitos deles.

Wes: Estou curioso sobre sua visão do futuro dos preços: veremos empresas gastando US$ 1.000, US$ 2.000 por mês por funcionário, ou os preços se estabilizarão com o surgimento de novos chips e coisas assim?

Dax: Temos os dados do último mês e, com o aumento exponencial no uso da empresa, calculamos os custos e os comparamos com a folha de pagamento. Para nós, esse nível de uso já é significativo, cerca de 15% do salário. Ou seja, para cada valor que você paga à sua equipe, precisa adicionar mais 15% de “imposto” para permitir o uso desses modelos. Honestamente, não é tão ruim. Empresas de tecnologia como a nossa geralmente têm alta receita por funcionário, e 15% é insignificante no contexto geral. Mas nem todos os setores são assim.

No entanto, esses preços cairão — e cairão muito. Se você for sensível ao preço, os modelos de código aberto são muito mais baratos. Acho que isso é confuso, pois há muitas manchetes dizendo que a OpenAI e a Anthropic estão perdendo dinheiro e nunca conseguirão ter sucesso, mas as margens de lucro de inferência são absurdamente altas, especialmente agora que a OpenAI e a Anthropic ainda estão aumentando os preços. Estimo que suas margens de lucro de inferência estejam em torno de 90%, o que significa que o ponto de equilíbrio poderia ser 10 vezes mais barato.

Wes: Alguém me disse anteriormente que a margem de lucro para inferência é de 70%, então entre 70% e 90%. Isso claramente não é apenas o custo de treinar o modelo, certo?

Dax: Claro, há também os custos de pesquisa e desenvolvimento. Mas como uma empresa, você analisa essas duas coisas separadamente, pois pode encerrar a pesquisa e desenvolvimento e ainda assim lucrar.

Wes: E quanto às pessoas que acham que podem executar modelos localmente? O que você pensa sobre aqueles que acreditam que podem rodar máquinas no próprio quintal?

Dax: Sou muito cauteloso ao abordar esse tópico, pois as pessoas nessa comunidade se irritam facilmente. Então, primeiro, devo esclarecer: há muitas razões válidas para as pessoas quererem executar modelos localmente. Se você simplesmente não quer que seus dados saiam de casa, isso é totalmente compreensível. Mas se o seu foco é o custo, modelos locais não o ajudarão a economizar dinheiro, porque qualquer mecanismo que torne o hospedagem local mais barata também tornará a hospedagem na nuvem dez vezes mais barata. Se um modelo se tornar mais eficiente ou conseguir maior desempenho com um tamanho menor, isso apenas reduzirá ainda mais o custo por token na nuvem. Portanto, acho que modelos locais são mais uma questão de privacidade do que de custo.

Nós usamos intermediários para hospedar GPUs, mas mesmo assim, conseguimos hospedar alguns modelos com custos 70% abaixo do preço de tabela, o que é muito barato. Isso significa que, vendendo ao preço de tabela, podemos obter uma margem de lucro de 70%, mesmo com intermediários. Se você comprar GPUs diretamente, provavelmente alcançará a margem de lucro de 90% que estimei para a Anthropic, ou seja, os custos podem ser extremamente baixos. Claro, isso se aplica a modelos abertos. Ainda dependemos de modelos abertos continuarem melhorando, mas a tendência atual está realmente nessa direção.

OpenCode foi "baniu" pelo Claude Code?

Scott: Vamos falar sobre o Claude Code. Parece que a posição deles sempre foi muito ambígua — provedores como o OpenCode podem usar o plano Claude Code Max? Qual é a situação atual?

Dax: Sobre essa integração, o plugin no OpenCode que o obriga a usar o plano Max é absolutamente proibido. Discutimos muito com eles sobre isso e, no final, não vencemos. Claro, as pessoas sempre encontram maneiras de contornar as restrições por meio de hacks, mas não podemos oficialmente apoiar essa prática.

Quanto ao SDK, o modo headless para chamar o Claude está atualmente em uma área cinzenta; eles atualmente dizem que é permitido. Portanto, produtos como o Conductor podem embalá-lo, e o T3 Code também pode embalá-lo. Mas nós nunca vamos embalar isso, pois isso vai contra em grande parte a intenção original do OpenCode. Então, essas ferramentas de orquestração ou interfaces alternativas — acho que esses produtos ainda podem ser usados, mas, novamente, a situação ainda é incerta.

No final das contas, isso é um problema de cultura da empresa: você é uma empresa muito voltada para o consumidor ou uma empresa voltada para o negócio? A OpenAI é muito uma empresa voltada para o consumidor, o que significa que eles gastarão qualquer quantidade de dinheiro, arrecadarão qualquer quantidade de dinheiro, para levar a experiência a mais pessoas — é por isso que a assinatura da OpenAI é oficialmente suportada no OpenCode, e acho que a Anthropic não possui exatamente a mesma cultura.

Se você for uma empresa voltada para empresas, a situação é completamente diferente, pois cada inferência alocada para uso do consumidor será acompanhada por um vendedor dizendo: “Tenho um cliente corporativo disposto a pagar o preço real.” Se sua capacidade de processamento for limitada, será difícil justificar internamente o uso por usuários do OpenCode. Embora agora sua capacidade de processamento provavelmente seja maior do que antes.

Scott: É por isso que eles não querem que você use? Muitas pessoas estão dizendo: “O que importa? Paguei pela assinatura, por que não posso usá-lo em qualquer lugar?” Alguns especulam que eles querem dados para treinamento, querem controle. Mas na verdade, é bem simples: eles simplesmente têm limitação de poder computacional?

Dax: Na verdade, cada empresa é essencialmente um funil; você coloca coisas na parte superior do funil para atrair usuários e, idealmente, os leva a se converter até a base.

Eles projetaram o Claude Code como um produto voltado para o topo do funil, muito voltado para o consumidor. Você o usa, sua empresa começa a usá-lo e, em seguida, sua empresa passa a pagar por Tokens. Mas se os usuários o utilizarem por meio do OpenCode, essa cadeia de conversão pode ser interrompida, pois no OpenCode você pode alternar livremente entre outros modelos. Se você não gostar do Claude, pode mudar a qualquer momento para o modelo mais popular atual.

A segunda razão é ainda a demanda competitiva por poder de mineração: qualquer coisa que você investir no topo do funil deve ser capaz de provar que acabará retornando ao fundo do funil. Se você for uma empresa voltada para o consumidor, pode ser mais flexível nesse aspecto.

Wes: Você já pensou se, no futuro, surgirá um modelo que não tenha API alguma, e você só poderá usá-lo por meio do aplicativo deles? Como a ElevenLabs, que tem um ótimo aplicativo, mas você precisa assinar um plano mensal e não pode pagar por uso. Você acha que isso vai acontecer?

Dax: Sim, isso novamente reflete a estrutura interna da empresa. A equipe de produtos apoiará fortemente essa abordagem, podendo dizer: “Podemos criar um modelo muito especializado, desenvolver um produto específico em torno dele e vincular os dois juntos; para usar o modelo, é necessário usar o nosso produto.” Isso é uma estratégia de bloqueio perfeita para equipes orientadas a produtos.

Mas a equipe de vendas tem metas de receita e dirá: “Nossa meta de receita é de 100 bilhões. Seu modelo de exclusividade de API ou de produto só pode gerar no máximo 50 bilhões; quem vai preencher os 50 bilhões restantes?” A equipe de vendas insistirá: “Não é possível; o modelo precisa ser incorporado à API, para que possamos atingir melhor nossas metas.” Enquanto esse conflito interno existir, será difícil para a organização justificar a renúncia a parte da receita em troca de participação de mercado.

À medida que esses laboratórios se tornam cada vez mais presentes no nível de produto, eles têm essencialmente um “botão injusto”, e não me surpreende que apertem em algum momento. E eles justificarão de maneiras estranhas, como: “Este modelo é muito perigoso; só é seguro dentro do nosso framework, não podemos permitir que seja usado em outros frameworks.” Essa não é realmente a razão, mas provavelmente será exatamente o que dirão.

Wes: Em relação à segurança do Fable, todos esses novos modelos são inseguros? O governo diz que eles são inseguros — isso é verdade ou apenas hype?

Dax: Acho que muitas coisas são verdadeiras e podem entrar em conflito entre si; esses modelos realmente têm o potencial de causar grandes danos. É razoável que o governo diga que precisamos de algum tipo de revisão antes do lançamento. Se você estiver em uma grande empresa como a Meta, quando lançam um produto, como uma função de carregamento de fotos de perfil, eles precisam provar ao governo que estão aplicando filtros contra pornografia infantil nessa função. Nessa escala, até mesmo as funcionalidades mais insignificantes dentro do aplicativo enfrentam um nível absurdo de regulamentação.

Mas o problema é que, se esse processo for muito ignorante ou corrupto, o resultado final não será uma aprovação abrangente do modelo e acesso amplo para todos, mas sim acesso desigual causado por processos governamentais — isso seria uma situação muito ruim, e espero que isso não aconteça. Eu preferiria ver um resultado mais entediante: sempre que eles lançarem um novo modelo, precisem apenas passar por um processo que leva um mês.

Por outro lado, isso não é uma questão totalmente racional. Acho que esses laboratórios não deveriam começar a afirmar descaradamente que possuem "armas nucleares", pois isso atrairia interesse político. É como brincar com uma bomba que pode acabar em uma situação entediante ou se tornar algo realmente ruim, como regulamentação inadequada, excessivamente agressiva e prejudicial a toda a economia. Por isso, espero que esses laboratórios sejam mais cautelosos em relação à percepção pública, pois você não pode ficar dizendo por aí que tem uma bomba atômica e esperar que nada aconteça.

A interação com IA está se tornando sem mãos

Scott: Vamos conversar sobre MCP, Skill e as ferramentas usadas para programação com IA. O que realmente vale a pena acompanhar e usar? O que vocês estão utilizando?

Dax: A maioria de nós tem configurações pessoais muito básicas. O que realmente é interessante é o bot do Discord interno da nossa equipe, que possui muito mais MCPs e habilidades do que nossas configurações pessoais. Temos algo chamado "Gang Growth", ideia de Kit Lang. Sempre que ficamos presos em algum problema de design — seja de negócio, API ou implementação — gravamos um prompt por voz no bot do Discord e marcamos o @OpenCode, que funciona como uma ferramenta de colaboração.

Este robô está conectado a todos os data lakes da empresa, e posso perguntar: “Na última semana, quanto os usuários de assinatura Go com cobrança excessiva gastaram no total?” e ele será capaz de calcular. A mudança no nosso modo de trabalho é: basicamente não há mais motivo para mencionar outra pessoa. Se você tiver uma dúvida, primeiro mencione o OpenCode. Se outras pessoas virem, elas se juntarão para ajudar. Mas o OpenCode muitas vezes resolve sozinho.

Scott: E se o robô precisar retornar informações para você? Agora todos estão discutindo sobre MCP UI ou gerar arquivos HTML diretamente. Você acha que, no futuro, como os Agentes de codificação apresentarão informações?

Dax: Certamente adicionaremos alguma funcionalidade de artifacts ao OpenCode para que ele possa gerar documentos e enviá-los a você. Ele usa HTML com SVG para visualização, é muito legal. Isso não exige nada de especial, apenas aproveita a capacidade do Agente. Quanto à MCP UI, ainda não a explorei profundamente, mas acredito que a suportaremos no aplicativo de desktop, especialmente quando começarmos a nos concentrar em não técnicos, pois acho que as perguntas que eles fazem e as tarefas que precisam realizar se beneficiariam de alguma interface dinâmica ou algo mais rico.

Nossa equipe está agora obcecada por voice prompting, e até mesmo quando nos enviamos mensagens no Discord, usamos voz, porque odiamos digitar. Quando você pode simplesmente falar com o sistema, muitas interfaces, especialmente interfaces interativas, prefiro apenas descrever aproximadamente o que preciso fazer. Se eu tiver que digitar tudo, certamente seria péssimo. Mas posso usar voz — a voz agora é muito rápida e funciona localmente.

Scott: Comprei um pedal porque há muitos comandos de voz. Um pedal é para "entrar", outro para "ativar dictação" e outro para alternar entre abas. Só fico sentado usando isso — é bem legal.

Dax: Muitas pessoas têm dúvidas sobre isso, e eu totalmente entendo, porque eu mesmo só comecei depois de ver Kit fazendo isso. Quando você vê alguém fazendo isso, algo se libera na sua cabeça. Se você nunca fez, pode parecer embaraçoso. Mas na verdade, é a coisa mais natural do mundo — você pode falar besteiras, se confundir, cometer erros de fala, não importa, porque os LLMs são excelentes em entender o que você realmente quer dizer.

Wes: Você está usando o aplicativo Hex da Kit?

Dax: Uso o Handy na máquina principal e o Hex no Mac. O modelo é bom, e isso é o que importa.

Wes: Meu método de ativação é simples: um botão pequeno no mouse, basta clicar duas vezes. Alguém também está criando um anel que pode ser tocado; eles vão me enviar um, e eu vou testar.

Dax: Ainda passo a maior parte do tempo com os dedos no teclado, então criei um atalho.

Wes: Há algo mais que não abordamos, mas que você quer especialmente mencionar? Por exemplo, alguma opinião pessoal sua?

Dax: Estou muito entusiasmado com o próximo modelo. Normalmente, quando um novo modelo é lançado, tudo parece igual, e até costumo postar reclamações sobre isso. Mas desta vez é a primeira vez que sinto que esses modelos realmente serão usados por muitas pessoas. Eles já foram lançados tecnicamente, apenas o governo ainda não permite que usuários comuns os utilizem.

Wes: Agora existem vários testes de desempenho e pontuações, e ao mesmo tempo todos estão dizendo "parece muito melhor". Você acha que finalmente conseguiremos um teste de desempenho verdadeiramente significativo?

Dax: Para ser honesto, agora nem olho mais para os testes de desempenho; nem tenho certeza se realmente já olhei antes. Acho que essas pontuações já se tornaram ruído de fundo. Todos sabemos que os números estão subindo, e subiram mais do que os concorrentes, mas quando os concorrentes lançam, suas pontuações sobem ainda mais — qual é realmente o sentido disso?

Então, agora eu me concentro apenas em feedback qualitativo. Gosto de ver as pessoas compartilhando o que conseguem fazer com o modelo ou o que construíram. É claro que você não pode obter esse tipo de feedback em escala de milhões de pontos de dados, mas esses produtos são intrinsicamente ambíguos e, no fim, se reduzem a: os usuários estão felizes? Os usuários estão frustrados? É por isso que gosto de observar o uso de tokens da nossa equipe. Se a curva está subindo, significa que algo está funcionando, que eles estão gostando de algo. Temos fãs de Claude, fãs de GPT e fãs de modelos open-source na nossa equipe, então temos uma boa cobertura em todas as direções.

Scott: Você tem algo especial que tenha aproveitado recentemente e que queira compartilhar?

Dax: Claro, é o exe.dev que mencionei anteriormente. Se você quiser experimentar o conceito de "máquina na nuvem", é um produto muito inteligente, feito muito bem. Ele me dá a mesma sensação que o Tailscale — algo que simplesmente funciona — e o exe.dev tem a mesma vibe. Eu adoro produtos que encontram um nicho preciso, e este se encaixa perfeitamente em um vazio estranho. Você pode alugar servidores na AWS ou em outros lugares, mas é difícil encontrar facilmente um servidor com disco de armazenamento rápido e persistente, a um preço razoável. Esse buraco profundo era preenchido apenas por provedores de VPS duvidosos, que surgiam e desapareciam.

Há alguns anos, quando montei meu primeiro servidor de desenvolvimento, procurei a opção mais barata e acabei encontrando um provedor VPS em Miami. Esse cara falsificou sua própria morte, e o servidor foi desligado. Ele enviou e-mails para todos dizendo: “Vou fazer uma cirurgia médica e ficarei inacessível por três dias”, e três dias depois, o servidor realmente caiu. Pensei: “Caramba, algo aconteceu?” Um mês se passou e ninguém conseguiu entrar em contato com ele. Por fim, encontrei um post em um fórum onde alguém descobriu que ele já havia operado outro serviço VPS e desaparecera em circunstâncias semelhantes. O mercado de servidores baratos e de alto desempenho é simplesmente incrivelmente inconfiável. Até hoje não entendo: que tipo de golpe é esse? Eu paguei por um serviço, então por que ele simplesmente desapareceu?

Wes: O que você gostaria de recomendar aos espectadores?

Dax: Se for algo seu, recomendo o OpenTUI. É uma ótima maneira de construir TUIs. Você pode criar TUIs de alto desempenho usando React, SolidJS ou até bindings do Vue. O OpenCode foi construído com isso, e estamos avançando em direção à versão 1.0. Recentemente, houve um renascimento de produtos e aplicativos de terminal.

Scott: Quem mais está usando isso? Também é algo novo do Grok ou da xAI?

Dax: O CLI do Grok está muito bem feito, executa perfeitamente e tem excelente desempenho, mas foi escrito em Rust, e provavelmente eles usam a biblioteca Ratatouille. No entanto, o novo proxy TUI do Hermes foi construído com o OpenTUI. A comunidade está crescendo rapidamente, e agora, sempre que vejo um TUI na minha linha do tempo, é provavelmente OpenTUI, especialmente porque você pode escrever usando o estilo vibe coding, pois é essencialmente React.