Melhores modelos para OpenCode: 7 critérios para escolher

Não existe um vencedor universal. Comece com um modelo hospedado confiável para raciocínio complexo, use um modelo equilibrado para alterações diárias de código e escolha um modelo local quando privacidade ou trabalho offline forem prioridade. Modelos gratuitos ou incluídos ajudam a testar um fluxo, mas não garantem qualidade permanente.

Um modelo ótimo para planejar arquitetura pode ser exagero para uma alteração pequena. Separe o trabalho em raciocínio e planejamento, implementação, documentação e transformações rápidas. Planejamento exige consistência em várias etapas; implementação exige edição precisa; documentação valoriza clareza e velocidade.

Para escolher os melhores modelos para OpenCode, registre a saída esperada, o custo do erro, o contexto do repositório e as ferramentas necessárias. Uma explicação somente de leitura pode começar com um modelo rápido. Uma migração que altera muitos arquivos merece um modelo mais forte e um diff revisado.

Não use melhor modelo como substituto de um requisito. Em pequenas edições a latência pode ser mais importante; em um incidente de produção, confiabilidade e rastreabilidade podem valer mais que uma pequena diferença de preço. O fluxo seguinte torna o compromisso explícito.

Modelos hospedados costumam ser o primeiro teste porque o provedor gerencia o ambiente. Eles servem para raciocínio, contexto e ferramentas estáveis, mas exigem rede, política e custo. Verifique o tratamento do código privado antes de enviá-lo.

Um modelo local depende de memória, computação, quantização, runtime e suporte a ferramentas; não é apenas um modelo hospedado mais barato. Pode ser ideal para privacidade e offline, mas exige prompts menores. Use o guia de Ollama para os detalhes de conexão.

Um plano ou assinatura pode simplificar a cobrança, mas cotas, modelos disponíveis e limites também mudam. Separe a decisão de preço da capacidade real do modelo.

Mais contexto não significa resposta melhor. Comece com os arquivos mínimos que comprovam a tarefa e amplie apenas quando faltarem evidências. Confira o que o agente pode ler e quais ferramentas estão ativas.

A latência importa no terminal interativo. Confiabilidade inclui formato consistente, escolha correta de ferramentas, reconhecimento de limites e falhas previsíveis. Privacidade é uma restrição do projeto, não uma palavra de marketing.

Use a mesma tarefa, prompt e contexto em cada candidato. Registre tempo até a resposta útil, erros, arquivos alterados e correções necessárias, junto do ID e da data do modelo.

A configuração de modelos do OpenCode usa o padrão provider/model. Verifique o ID exato na documentação atual do provedor e mantenha credenciais no fluxo de autenticação ou em variáveis de ambiente.

Uma configuração mínima é mais fácil de revisar que um catálogo copiado. Teste primeiro uma tarefa de baixo risco e registre o motivo da escolha. As páginas oficiais Models e Config são a referência do esquema.

{
  "$schema": "https://opencode.ai/config.json",
  "model": "provider/model-id"
}

Não avalie um modelo com uma demonstração chamativa. Use uma tarefa real: explicar um módulo, propor um plano, fazer uma alteração limitada e revisar o diff. Mantenha repositório, prompt e critérios iguais.

Registre correção, completude, custo de interação e risco. Anote espera, perguntas de acompanhamento, comandos não autorizados e arquivos inesperados. Uma resposta convincente que ignora uma restrição não deve ser o padrão.

Troque apenas quando o padrão de falha se repetir. Reduza o contexto para tarefas longas, verifique permissões quando ferramentas falharem e teste um modelo local menor quando o problema for velocidade.

1. Fixar a tarefaManter tarefa, snapshot, prompt e checklist.
2. Começar somente leituraPedir premissas e plano antes de permitir escrita.
3. MedirRegistrar tempo útil, erros, perguntas e arquivos.
4. Revisar o diffRecusar alterações sem explicação ou teste.
5. Escolher o padrãoFicar com o modelo que passa o limite com menor risco prático.

Rankings usam prompts, ferramentas, contextos e datas diferentes. Trate-os como hipótese e valide em um benchmark pequeno do seu repositório.

Modelos gratuitos são úteis para aprender, mas cotas, fila, contexto e disponibilidade variam. Mantenha-os em tarefas de baixo risco até passarem pelo mesmo teste.

Antes de trocar, confirme provedor, ID, autenticação, permissões e configuração ativa. Um ID incorreto ou contexto grande pode parecer um problema de qualidade.

Catálogos mudam mais rápido que o processo do repositório. Preserve tipo de tarefa, limite de contexto, verificações e rollback; atualize o ID e as medições quando o provedor mudar. Não prometa que um modelo será sempre o melhor.

Para continuar, use Ollama para modelos locais, Go e Zen para planos, JSONC para configuração e MCP para ferramentas e permissões. Esta página é a camada de decisão.