Índice

• Primeiro, vamos esclarecer os três nomes que todo mundo confunde
• Tabela comparativa: BYOK, Zen e Go
• O que realmente cabe em 10 dólares
• O custo real por turno, para colocar as coisas em perspectiva
• Minha recomendação: separe o design da execução

  • Por que isso funciona tecnicamente
  • O fluxo concreto, passo a passo
  • Exemplo de spec executável
• Casos borde
• Criterios de aceptación
• Verificación

Primeiro, vamos esclarecer os três nomes que todo mundo confunde

OpenCode é um agente de código de terminal, open source, mantido pela Anomaly. É a ferramenta: uma TUI onde você escreve, um agente que lê seu repositório, edita arquivos, roda comandos e mostra os diffs. É gratuito e sempre foi.

OpenCode Zen é outra coisa. É um gateway de modelos — um intermediário — que o time da OpenCode construiu depois de esbarrar num problema real: existem dezenas de modelos que dizem servir para programar, mas muito poucos funcionam bem como agentes, e os que funcionam bem entregam resultados bem diferentes dependendo de qual provedor os serve. Um mesmo modelo pode render excelente em um provedor e medíocre em outro, com o mesmo rótulo. O Zen é a resposta a isso: testaram modelos, conversaram com os times que os treinam, negociaram com provedores para que os servissem corretamente, fizeram benchmarks da combinação modelo/provedor, e publicaram uma lista curada. Paga-se por uso, com preços por milhão de tokens e sem markup declarado além das taxas de processamento de pagamento.

OpenCode Go é a terceira peça, e a mais recente: uma assinatura fixa de 10 dólares por mês (5 no primeiro mês) que dá acesso a um subconjunto dessa lista — os modelos abertos — com limites de uso denominados em dólares em vez de em tokens. Não é um plano "ilimitado" nem pretende ser. É um plano com um multiplicador declarado: você paga 10 e o objetivo do time é te dar cerca de 60 dólares de uso.

💡 Ganhe $5 de crédito para os seus limites de uso Se você se cadastrar com este link do OpenCode Go, recebe $5 de crédito aplicados diretamente aos seus limites de uso. Praticamente cobre o seu primeiro mês de teste antes de gastar um centavo.

Os três são independentes. Você pode usar o OpenCode com suas próprias chaves da OpenAI ou da Anthropic e não pagar um centavo nem para o Zen nem para o Go. Você pode usar o Zen a partir de outro agente que não seja o OpenCode. E você pode ter Go e Zen ao mesmo tempo, que é justamente o que recomendo mais adiante.

Tabela comparativa: BYOK, Zen e Go

	OpenCode BYOK	OpenCode Zen	OpenCode Go
Modelo de cobrança	Gratuito (você paga o provedor)	Pago por uso, pré-pago com saldo	Assinatura fixa
Preço	$0 + o que você gastar na sua API	Conforme os tokens consumidos	$5 no primeiro mês, depois $10/mês
Catálogo	Qualquer provedor que você suportar	~70 modelos: Claude, GPT, Gemini, Grok, Qwen, DeepSeek, GLM, Kimi, MiniMax	18 modelos abertos: Grok 4.5, GLM-5.2/5.1, GPT 5.6 Luna, Kimi K3/K2.7/K2.6, Qwen3.8/3.7/3.6, DeepSeek V4 Pro/Flash, MiniMax M3/M2.7, MiMo-V2.5, Hy3
Modelos de fronteira	Sim, se você pagar a API	Sim (Claude Opus 5, GPT 5.6 Sol, Gemini 3.1 Pro, Claude Fable 5)	Não, exceto Grok 4.5 e GPT 5.6 Luna
Limites	Os do seu provedor	Seu saldo e o limite mensal que você configurar	$12 a cada 5 horas · $30/semana · $60/mês
Recarga automática	N/A	Sim: se cair abaixo de $5, recarrega $20 (configurável ou desativável)	N/A, é fixo
Ao esgotar o limite	N/A	Recarrega ou para	Você continua com os modelos gratuitos, ou cai para o seu saldo Zen se ativar "Use balance"
Equipes	Manual	Workspaces com papéis, limites por membro, modelos habilitáveis (gratuito em beta)	Só um membro por workspace pode assinar
Retenção de dados	A do seu provedor	Retenção zero, salvo exceções documentadas	0 dias em quase todos; 30 dias em Grok 4.5 e GPT 5.6 Luna
Bring your own key	É o modo padrão	Sim, você pode usar suas chaves da OpenAI/Anthropic dentro do Zen	Não
Para quem	Quem já tem contratos ou créditos	Quem precisa de modelos de fronteira e controle fino	Quem executa muito e decide pouco

A leitura rápida desta tabela: o Zen é um catálogo completo com preços de mercado, o Go é um subconjunto barato com teto. Eles não competem, se complementam.

O que realmente cabe em 10 dólares

É aqui que a maioria das resenhas fica devendo, porque repete a manchete — "18 modelos por 10 dólares" — sem explicar a mecânica que realmente determina o que você pode fazer.

O Go não te dá tokens. Ele te dá orçamento em dólares, e esse orçamento se consome na velocidade que o preço do modelo escolhido determinar. Há três bolsos simultâneos: 12 dólares a cada cinco horas, 30 dólares por semana e 60 dólares por mês. O de cinco horas é um corta-fogo contra sessões descontroladas; o semanal impede que você torre o mês em três dias; o mensal é o teto real.

Mas há uma segunda camada que quase ninguém menciona e que é a mais importante: nem todos os modelos têm o mesmo orçamento atribuído. A documentação oficial publica uma coluna de "usage" por modelo, e nela dá para ver que uns trazem 60 dólares de uso incluídos e outros só 15. A explicação do time é honesta: para a maioria dos modelos eles conseguiram descontos por volume e capacidade de GPU reservada, e repassam essa economia no multiplicador de 6x. Para os que não conseguiram — porque são muito novos ou porque o preço público já vem descontado — o multiplicador cai para 1.5x.

Isso divide o catálogo do Go em duas ligas:

Liga de 60 dólares (multiplicador 6x): GLM-5.2, GLM-5.1, Kimi K2.7 Code, Kimi K2.6, MiMo-V2.5, MiniMax M3, MiniMax M2.7, Qwen3.7 Max, Qwen3.7 Plus, Qwen3.6 Plus, DeepSeek V4 Flash, Hy3.

Liga de 15 dólares (multiplicador 1.5x): Grok 4.5, GPT 5.6 Luna, Kimi K3, MiMo-V2.5-Pro, Qwen3.8 Max, DeepSeek V4 Pro.

Traduzido em pedidos reais, segundo as estimativas que a OpenCode publica com base nos padrões de uso observados:

Modelo	Pedidos / 5h	Pedidos / semana	Pedidos / mês	Liga
DeepSeek V4 Flash	31.650	79.050	158.150	60
MiMo-V2.5	30.100	75.200	150.400	60
Qwen3.7 Plus	4.300	10.800	21.600	60
Hy3	4.300	10.750	21.500	60
MiniMax M2.7	3.400	8.500	17.000	60
DeepSeek V4 Pro	3.450	8.550	17.150	15
Qwen3.6 Plus	3.300	8.200	16.300	60
MiMo-V2.5-Pro	3.250	8.150	16.300	15
MiniMax M3	3.200	8.000	16.000	60
Kimi K2.7 Code	1.350	3.380	6.750	60
Kimi K2.6	1.150	2.880	5.750	60
GLM-5.2 / GLM-5.1	880	2.150	4.300	60
Qwen3.7 Max	340	840	1.690	60
GPT 5.6 Luna	2.050	5.100	10.250	15
Qwen3.8 Max	160	400	810	15
Grok 4.5	120	300	600	15
Kimi K3	110	250	490	15

Olha o salto: o DeepSeek V4 Flash te dá 158.000 pedidos por mês; o Kimi K3 te dá 490. É um fator de 320x entre o extremo barato e o caro dentro do mesmo plano de 10 dólares. Quem usar o Go como se fosse um buffet de "escolha sempre o melhor modelo" vai esbarrar no limite de cinco horas já no primeiro dia.

E é preciso dimensionar os números altos com critério. Uma tarefa agêntica de verdade — "adicione autenticação com JWT a este endpoint, escreva os testes e atualize a documentação" — não é um pedido. São entre 30 e 150 turnos: ler arquivos, propor um diff, rodar os testes, ver que falham, corrigir, rodar de novo. Com essa régua, 4.300 pedidos mensais do GLM-5.2 equivalem a aproximadamente entre 30 e 100 tarefas médias por mês. Para um desenvolvedor individual ou um side project, isso é folgado. Para uma equipe de quatro pessoas compartilhando uma conta, não é — e, de fato, não é permitido: só um membro por workspace pode assinar o Go.

Se o que você busca é um detalhamento focado só no preço e nos limites do Go, sem a parte do Zen nem de estratégia, tenho uma resenha dedicada: OpenCode Go: preço, limites de uso e se vale a pena em 2026.

O custo real por turno, para colocar as coisas em perspectiva

Para entender por que a estratégia que proponho funciona, ajuda calcular quanto custa um turno agêntico típico em cada modelo. Uso um perfil realista e constante — cerca de 800 tokens de entrada nova, 60.000 tokens lidos de cache (o contexto do repositório, que é o que domina o gasto) e 250 tokens de saída — e aplico os preços públicos do Zen:

Modelo	Custo estimado por turno	Turnos por cada $1
GPT 5.6 Luna	$0,00166	~600
DeepSeek V4 Flash	$0,00186	~540
MiniMax M3	$0,0041	~240
Kimi K2.7 Code	$0,0132	~76
Claude Sonnet 5	$0,0161	~62
GLM-5.2	$0,0178	~56
Grok 4.5	$0,0211	~47
Claude Opus 5	$0,0403	~25
GPT 5.6 Sol	$0,0415	~24
Claude Fable 5	$0,0805	~12

Estimativa própria com base no perfil descrito e nos preços publicados na documentação do Zen (dentro do Go, alguns desses modelos saem ainda mais baratos). Seu consumo real vai variar conforme o tamanho do seu repositório e o quanto você aproveita o cache.

O que salta aos olhos é que a diferença entre o modelo de fronteira e o modelo braçal não é de 30% nem do dobro: o Claude Fable 5 custa mais de quarenta vezes o que custa o GPT 5.6 Luna ou o DeepSeek V4 Flash pelo mesmo turno, e dentro do plano Go essa brecha se alarga ainda mais. E aqui vem a pergunta incômoda: será que esses 150 turnos de "leia o arquivo, aplique o diff, rode o teste" realmente precisam do melhor modelo do mundo?

Quase nunca. O que de fato precisa do melhor modelo do mundo é a decisão do que construir e como. E essa decisão são cinco ou dez turnos, não cento e cinquenta.

Minha recomendação: separe o design da execução

Aqui está o núcleo do artigo. Meu fluxo, depois de bastante tentativa e erro, é este: defino o spec com Claude ou Grok, e executo o spec com o OpenCode Go.

Pessoalmente, uso principalmente o Claude — Opus 5 quando a decisão é arquitetural e Sonnet 5 para specs mais rotineiros — e o Grok quando quero uma segunda opinião com um viés diferente ou quando preciso que o modelo seja direto e não complacente. O Codex funciona igualmente bem para essa fase se for a sua ferramenta habitual; o ponto não é a marca, é o papel.

A lógica é a mesma que aplicamos em qualquer metodologia ágil séria: o refinamento e a execução são atividades distintas, com custos e perfis de risco distintos. Ninguém coloca o arquiteto para escrever os testes unitários, e ninguém pede para o júnior decidir o modelo de dados. Quando você mistura as duas coisas em uma única conversa com um modelo de fronteira, paga preço de arquiteto por trabalho de execução durante horas.

Por que isso funciona tecnicamente

Um modelo de execução não precisa de criatividade; precisa de obediência e competência. Se o spec é bom — se diz quais arquivos tocar, qual contrato cumprir, quais casos de borda cobrir e como se verifica o sucesso — então a tarefa deixa de ser "projete isto" e passa a ser "transcreva isto em código e valide". Modelos como GLM-5.2 ou Kimi K2.7 Code fazem isso perfeitamente bem.

Quando o spec é ruim, por outro lado, o modelo de execução começa a improvisar. E é aí que as pessoas concluem que "os modelos abertos não prestam". Não é que não prestem: é que você pediu para eles fazerem dois trabalhos e só pagou por um.

O fluxo concreto, passo a passo

1. Conversa de design com Claude ou Grok. Ainda sem código. Descreva o problema, o contexto do negócio e as restrições. Peça explicitamente para que ele te faça perguntas antes de propor algo. Aqui você gasta entre 5 e 15 turnos de um modelo caro, e são os turnos mais bem investidos do processo.

2. Gere o spec como arquivo. Peça a saída em markdown, com esta estrutura mínima: objetivo, contexto (o que existe hoje), escopo explícito, fora do escopo explícito, arquivos a tocar, contratos e interfaces, casos de borda, critérios de aceitação verificáveis e plano de verificação. Guarde no repositório, por exemplo em specs/2026-08-12-auth-jwt.md. Viver no git faz parte do ponto: é documentação e é rastreabilidade.

3. Divida em tarefas atômicas. Cada tarefa do spec deve ser algo que um agente consiga completar e verificar sem ambiguidade. Se uma tarefa precisa de uma decisão de produto no meio do caminho, ela não está pronta para ser executada; volte ao passo 1.

4. Execute com o OpenCode Go. Abra o OpenCode no repositório, aponte para o spec, e deixe o modelo braçal trabalhar. Minha atribuição padrão é GLM-5.2 ou Kimi K2.7 Code para a implementação principal, MiniMax M3 ou DeepSeek V4 Flash para tarefas mecânicas (renomear, migrar sintaxe, gerar testes repetitivos, atualizar imports).

5. Revisão com o modelo caro, só se for preciso. Se os testes passam e o diff é legível, não é preciso. Se algo cheira estranho, passe o diff para o Claude ou o Grok com a pergunta concreta. São três turnos, não trinta.

Exemplo de spec executável

# Spec: Rate limiting no endpoint público de busca

## Objetivo
Evitar abuso del endpoint `GET /api/search`, hoy sin protección.

## Contexto
- Express 4 + Redis ya disponible en `src/lib/redis.ts`
- Middleware de auth en `src/middleware/auth.ts` (patrón a imitar)
- No hay tests de middleware todavía

## Alcance
- Middleware `rateLimit` reutilizable, configurable por ruta
- Aplicarlo solo a `GET /api/search`
- Ventana deslizante en Redis, 60 peticiones / 60s por IP
- Responder 429 con header `Retry-After`

## Fuera de alcance
- Rate limiting por usuario autenticado (fase 2)
- Dashboard de métricas
- Cambios en el algoritmo de búsqueda

## Archivos
- Crear: `src/middleware/rateLimit.ts`
- Crear: `src/middleware/__tests__/rateLimit.test.ts`
- Modificar: `src/routes/search.ts` (solo añadir el middleware)

## Contrato
```ts
rateLimit(opts: { windowMs: number; max: number; keyPrefix: string }): RequestHandler

Casos borde

• Redis caído → dejar pasar la petición y loguear warning (fail-open)
• IP ausente en el request → usar req.socket.remoteAddress, y si tampoco, no limitar
• Reloj: usar Date.now() del servidor, no timestamps del cliente

Criterios de aceptación

• 60 peticiones en 60s pasan; la 61 devuelve 429
• El header Retry-After trae segundos hasta el reset
• Con Redis caído los tests siguen en verde
• npm test y npm run lint en verde
• Ningún archivo fuera de la lista de "Archivos" queda modificado

Verificación

Ejecutar npm test -- rateLimit y npm run lint.

Um spec assim o GLM-5.2 executa sem despentear o cabelo, provavelmente em 25-40 turnos. A ~0,014 dólares de orçamento Go por turno, estamos falando de meio dólar da sua alocação mensal de 60. Você pode fazer isso mais de cem vezes por mês.

## Escolher a IA de acordo com a necessidade e a complexidade

Este é o hábito que mais economiza — dinheiro e frustração — e o que menos gente cultiva. A pergunta certa antes de abrir qualquer chat não é "qual é o melhor modelo?", e sim "que tipo de trabalho é este?".

Eu penso nisso em quatro níveis.

**Nível 0 — Mecânico.** Renomear variáveis, converter um formato em outro, gerar boilerplate, traduzir um arquivo de configuração, escrever testes repetitivos a partir de um padrão já estabelecido. Não há decisões. Use o mais barato que existir: DeepSeek V4 Flash, MiMo-V2.5, GPT 5.6 Luna. Se o resultado sair errado, você percebe na hora e não custa nada tentar de novo.

**Nível 1 — Implementação guiada.** Há um spec claro e é preciso transformá-lo em código que compile, passe nos testes e respeite as convenções do projeto. Exige competência real, mas não julgamento de produto. É aqui que moram GLM-5.2, Kimi K2.7 Code, MiniMax M3, Qwen3.7 Plus. É 70% do trabalho real de programar e é exatamente o terreno do Go.

**Nível 2 — Design delimitado.** É preciso decidir algo, mas dentro de um quadro conhecido: como modelar esta tabela, qual padrão usar para este caso, como estruturar este módulo. Aqui a régua sobe: Grok 4.5, Claude Sonnet 5, GPT 5.6 Terra. São poucos turnos, então mesmo que custem mais, o impacto na fatura é menor do que você teme.

**Nível 3 — Decisão com consequências.** Arquitetura, estratégia de migração, escolha de tecnologia, análise de um incidente confuso, qualquer coisa em que errar custa semanas. Modelo de fronteira, sem hesitar: Claude Opus 5, Claude Fable 5, GPT 5.6 Sol, Gemini 3.1 Pro. E aqui vale o luxo da segunda opinião: fazer a mesma pergunta a dois modelos de famílias diferentes e comparar. Quando os dois concordam, você tem um sinal razoável; quando divergem, você encontrou exatamente o ponto em que precisava pensar por conta própria.

A regra que resume tudo: **o modelo caro decide, o modelo barato executa.** E o corolário, que é igualmente importante: se você se pegar usando um modelo de fronteira no octogésimo turno da mesma tarefa, alguma coisa deu errado na etapa de design. Volte ao spec.

Há uma nuance que vale a pena explicitar, porque toca a parte filosófica de tudo isso. A tentação de usar sempre o melhor modelo não é econômica, é psicológica: dá mais sensação de segurança. Mas essa sensação de segurança tem um preço real, e não é só o da fatura. Quando você delega tudo ao modelo mais capaz, deixa de distinguir entre as decisões que importam e as que não importam. Se forçar a classificar a tarefa antes de escolher a ferramenta é, no fundo, um exercício de critério. E o critério é a única coisa que não pode ser terceirizada.

## Dez dicas práticas para espremer o plano Go

**1. Configure seu modelo padrão para o braçal, não para o caro.** No seu `opencode.json`, deixe `opencode-go/glm-5.2` ou `opencode-go/kimi-k2.7-code` como modelo principal. Subir de nível deve ser um ato consciente, não o estado padrão.

**2. Use o sistema de agentes do OpenCode para atribuir modelos por papel.** O OpenCode permite definir agentes distintos com modelos distintos. Um agente `plan` com um modelo capaz que só lê e propõe, e um agente `build` com um modelo barato que executa. É o fluxo deste artigo, automatizado.

**3. Escreva um `AGENTS.md` na raiz do repositório.** Convenções, comandos de teste, estrutura de pastas, o que não tocar. Cada coisa que está ali é uma coisa que o modelo braçal não precisa adivinhar, e adivinhar é o que consome turnos.

**4. Aproveite o cache.** O grosso do custo por turno é leitura de cache, não tokens novos. Sessões longas sobre o mesmo contexto saem muito mais baratas por turno do que abrir uma sessão nova para cada tarefinha. Agrupe o trabalho relacionado.

**5. Fique de olho no limite de cinco horas, não no mensal.** O teto que realmente vai te morder é o de 12 dólares a cada cinco horas. Se for fazer uma sessão intensa, comece com o modelo barato e reserve o caro para quando emperrar.

**6. Ative "Use balance" só se tiver saldo no Zen e souber por quê.** É a válvula de escape: quando você esgota o Go, ele continua puxando do seu saldo de pagamento por uso em vez de travar. Muito útil num deadline, perigoso se você deixar ativado e esquecer.

**7. Os modelos gratuitos do Zen continuam disponíveis quando você esgota o Go.** Há uma lista de modelos em período gratuito (DeepSeek V4 Flash Free, MiMo-V2.5 Free, Hy3 Free, Nemotron, LongCat, entre outros). Cuidado com a letra miúda: durante o período gratuito os dados podem ser usados para melhorar o modelo. Não os use com código confidencial.

**8. Revise a tabela de privacidade antes de colocar código de cliente.** No Go, a maioria dos modelos tem retenção de 0 dias, mas Grok 4.5 e GPT 5.6 Luna retêm por 30. Se você trabalha com código sob NDA, essa coluna importa mais do que o benchmark.

**9. Mantenha saldo no Zen mesmo usando o Go.** Dez dólares de Go mais vinte de saldo Zen te dão o melhor dos dois mundos: execução praticamente ilimitada, e acesso pontual a modelos de fronteira quando a decisão justificar. Ainda assim é menos do que custa uma única assinatura premium.

**10. Meça.** O console da OpenCode mostra o seu consumo. Olhe uma vez por semana durante um mês e você vai descobrir que 80% do seu gasto vem de dois ou três tipos de tarefa. São essas que precisam ser movidas para modelos baratos ou, melhor ainda, automatizadas com um spec reutilizável.

## Ferramentas práticas que acompanham bem esse fluxo

**OpenCode** (`opencode.ai`) é a base: TUI, CLI, modo servidor, integração com IDE, suporte a MCP e a Agent Skills. Instalação em uma linha, funciona em macOS, Linux e Windows via WSL.

**O comando `/connect`** dentro da TUI é como você conecta o Go ou o Zen: ele pede a API key que você copia do console em `opencode.ai/auth`, e com `/models` você vê o catálogo disponível. Na sua configuração, os IDs levam o prefixo do provedor: `opencode-go/kimi-k3` para o Go, `opencode/gpt-5.6-sol` para o Zen.

**Claude Code, Codex CLI ou Grok** para a fase de design. Qualquer um serve; o que importa é que a conversa do spec aconteça em um lugar diferente do da execução, ainda que só para não misturar contextos.

**Um diretório `specs/` versionado no git.** Parece pouco e é metade do valor deste método. Os specs se acumulam, são reaproveitados, viram modelos e — isso é o melhor — se tornam o melhor onboarding possível para qualquer pessoa ou agente que chegue depois.

**Servidores MCP** para dar contexto real ao agente: acesso ao seu banco de dados, ao seu gerenciador de tarefas, à sua documentação. Um agente com contexto precisa de menos turnos, e menos turnos é menos orçamento consumido.

**Os endpoints diretos do Go**, se você quiser construir algo em cima. `https://opencode.ai/zen/go/v1/chat/completions` é compatível com o SDK da OpenAI, e alguns modelos expõem o formato da Anthropic em `/v1/messages`. Você pode usar a sua assinatura do Go a partir dos seus próprios scripts, não só pela TUI.

## Quando o Go não é a resposta

Por honestidade, três cenários em que eu não o recomendaria.

Se o seu trabalho é majoritariamente de nível 3 — consultoria de arquitetura, pesquisa, análise — o Go vai te servir de pouco, porque o valor está nos modelos que ele não inclui. Pague o Zen por uso e pronto.

Se vocês são uma equipe, o Go não escala: só um membro por workspace pode assinar. Para equipes, o caminho é um workspace do Zen com limites de gasto por membro e modelos habilitados conforme o papel.

E se o seu código for estritamente confidencial, revise a tabela de retenção modelo por modelo e considere BYOK com um provedor com quem você já tenha acordo contratual. Dez dólares é barato, mas não o suficiente para pular essa conversa.

## Fechamento

A conclusão que levo depois de meses com esse fluxo não é sobre a OpenCode. É sobre como pensamos o gasto em IA de modo geral: continuamos comprando ferramentas quando o que deveríamos estar desenhando são processos.

Dez dólares por mês rendem muitíssimo se a execução chega com instruções claras, e rendem bem pouco se você os usa como substituto do pensamento. O plano Go não te torna mais produtivo por si só; ele te obriga — por design, através dos seus limites — a decidir o que merece um modelo caro e o que não merece. E essa disciplina, que parece uma restrição, acaba sendo o que faz o trabalho sair melhor.

Defina o spec com o melhor modelo que você conseguir pagar. Execute-o com o mais barato que aguentar. Guarde o spec no git. Repita.

> **🎁 Comece com $5 de crédito grátis**
> Antes de pagar o plano completo, [cadastre-se no OpenCode Go com este link](https://opencode.ai/go?ref=3CCYJM1AA3) e ganhe **$5 de crédito aplicados diretamente aos seus limites de uso**. É a forma mais barata de testar se o fluxo deste artigo encaixa com o seu jeito de trabalhar antes de se comprometer com o pagamento mensal.

## Perguntas frequentes

### O OpenCode Go substitui o Claude Code ou o Codex?

Não, e não deveria. O Go é um plano de execução com modelos abertos. Claude Code e Codex continuam sendo melhores para a fase de design e para tarefas que exigem julgamento. A proposta deste artigo é usá-los juntos, não escolher um.

### Posso ter Go e Zen ao mesmo tempo?

Sim, e é o que recomendo. O Go cobre a execução com orçamento fixo; o Zen te dá acesso pontual a modelos de fronteira. Além disso, você pode ativar a opção "Use balance" para que o Go caia para o seu saldo Zen quando você esgotar os limites, em vez de travar.

### Quantas tarefas reais cabem no plano de 10 dólares?

Depende do modelo. Com o GLM-5.2 (4.300 pedidos por mês) e tarefas de 30 a 150 turnos, estamos falando de entre 30 e 100 tarefas médias por mês. Com o DeepSeek V4 Flash, praticamente ilimitado para uso individual.

### Por que o Grok 4.5 só dá 600 pedidos por mês no Go?

Porque nem todos os modelos trazem o mesmo orçamento atribuído. A maioria inclui 60 dólares de uso (multiplicador 6x), mas alguns poucos — Grok 4.5, Kimi K3, GPT 5.6 Luna, Qwen3.8 Max, DeepSeek V4 Pro e MiMo-V2.5-Pro — incluem 15 (multiplicador 1.5x), porque o time ainda não conseguiu negociar descontos sobre eles.

### O que acontece se eu esgotar o limite?

Você pode continuar usando os modelos gratuitos do catálogo, ou ativar "Use balance" para puxar do seu saldo do Zen. Também pode esperar a janela de cinco horas ser reiniciada.

### O OpenCode Go serve para equipes?

Não diretamente: só um membro por workspace pode assinar. Para equipes, o caminho é um workspace do Zen com papéis, limites de gasto por membro e controle de quais modelos são habilitados.

### Meus dados são usados para treinar?

Nos modelos do Go, não. A retenção é de 0 dias em quase todos, com exceção de Grok 4.5 e GPT 5.6 Luna (30 dias, por políticas de combate a abuso dos seus provedores). Diferente é o caso dos modelos em período gratuito do Zen, onde os dados sim podem ser usados para melhorar o modelo.

## Continue lendo

Se você quiser só o preço, os limites e a minha experiência usando o OpenCode Go sozinho, sem a parte do Zen nem da estratégia de specs: [OpenCode Go: preço, limites de uso e se vale a pena em 2026](/pt/blogs/tecnologia/opencode-go-precio-limites-opinion).

Se você tiver interesse no restante do panorama de provedores de IA para programação, além da OpenCode: [Por que em 2026 você não deveria mais depender de um único provedor de IA para programar](/pt/blogs/tecnologia/diversificar-proveedores-ia).

## Fontes

- [OpenCode Go — documentação oficial](https://opencode.ai/docs/go/)
- [OpenCode Zen — documentação oficial](https://opencode.ai/docs/zen/)
- [OpenCode Go — página do produto](https://opencode.ai/go)
- [OpenCode Zen — página do produto](https://opencode.ai/zen)
- [OpenCode — documentação geral](https://opencode.ai/docs/)

*Preços, modelos e limites verificados em 12 de agosto de 2026. O catálogo da OpenCode muda com frequência; consulte a documentação oficial antes de tomar uma decisão de compra.*