Melhores LLMs para OpenCode - Testados Localmente

Testei como o OpenCode funciona com vários LLMs hospedados localmente via Ollama, e, para comparação, adicionei alguns modelos gratuitos do OpenCode Zen.

O OpenCode é uma das ferramentas mais promissoras no ecossistema de ferramentas de desenvolvimento de IA atualmente.

TL;DR - Melhores LLMs para OpenCode

Vencedor claro para uso local: Qwen 3.5 27b Q3_XXS no llama.cpp

A versão de 27b com quantização IQ3_XXS entregou um projeto Go completo e funcional, com todos os 8 testes de unidade passando, README completo e 34 tokens/segundo na minha configuração com 16GB de VRAM (CPU+GPU mistos). Cinco estrelas, sem ressalvas. Esta é a minha escolha principal para sessões locais do OpenCode.

Qwen 3.5 35b no llama.cpp — rápido para codificação, mas valide tudo

O modelo 35b é excelente para tarefas rápidas de codificação autônoma — mas meus testes de mapa de migração expuseram um problema sério de confiabilidade. Em duas execuções com IQ3_S, ele produziu 63–73% de incompatibilidades de slugs, e na quantização IQ4_XS ele esqueceu de incluir os slugs das páginas completamente, gerando caminhos de categoria que mapeariam 8 páginas diferentes para o mesmo URL. A qualidade de codificação na tarefa IndexNow foi genuinamente boa, então este modelo vale a pena usar — mas nunca confie na saída dele para tarefas estruturadas e que exigem seguir regras sem verificar. Validação não é opcional.

Surpreendentemente bom: Bigpicle (do OpenCode Zen)

O mais rápido para completar a tarefa — 1m 17s. Mais importante, foi o único modelo que pausou antes de codificar para realmente pesquisar a especificação do protocolo IndexNow usando a Exa Code Search. Ele encontrou todos os endpoints corretos na primeira tentativa. Se você tiver acesso ao OpenCode Zen, este modelo performa muito além do seu peso.

Bom, mas apenas com alto nível de raciocínio: GPT-OSS 20b

No modo padrão, o GPT-OSS 20b falha — ele encontra chamadas WebFetch que levam a becos sem saída e para. Mude para o modo de raciocínio alto e ele se torna um assistente de codificação genuinamente capaz: parsing completo de flags, lógica de lote correta, testes de unidade passando, tudo feito rapidamente. Tenha isso em mente antes de descartá-lo. O GPT-OSS 20b falhou em tarefas estruturadas mesmo no modo alto.

Pule para codificação autônoma: GPT-OSS 20b (padrão), Qwen 3 14b, devstral-small-2:24b

Estes costumavam ser os meus favoritos para velocidade em chat e tarefas de geração. Mas no modo autônomo, todos eles têm problemas reais. O Qwen 3 14b alucina documentação em vez de admitir que não consegue encontrar algo. O GPT-OSS 20b (padrão) trava quando o WebFetch falha. O Devstral confunde-se com operações básicas de arquivos. Para o OpenCode especificamente, a qualidade de seguir instruções e de chamadas de ferramentas importa muito mais do que a velocidade bruta.

Sobre este teste

Dei a cada modelo rodando no OpenCode duas tarefas/prompts:

1. Crie para mim uma ferramenta de linha de comando em Go que chame os endpoints IndexNow do Bing e de outros motores de busca para notificar sobre mudanças no meu site.
2. Prepare um mapa de migração de site.

Você sabe o que é o protocolo Indexnow, certo?

Para a segunda tarefa - tenho um plano de migrar alguns posts antigos neste site do formato de URL de blog (por exemplo https://www.glukhov.org/post/2024/10/digital-detox/) para clusters de tópicos (como a URL deste artigo: https://www.glukhov.org/ai-devtools/opencode/llms-comparison/). Então pedi a cada LLM no OpenCode para preparar um mapa de migração para mim, de acordo com minha estratégia.

Estava executando a maioria dos LLMs no Ollama hospedado localmente, e outros no llama.cpp também hospedado localmente. O Bigpicle e outros modelos de linguagem muito grandes eram do OpenCode Zen.

Resultado de cada modelo

qwen3.5:9b

Falha completa na primeira tarefa. O modelo passou pelo seu processo de raciocínio — identificando corretamente os serviços relevantes (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex) — mas nunca chamou nenhuma ferramenta. Produziu um resumo de “Build” sem tocar em um único arquivo. Nenhuma chamada de ferramenta.

qwen3.5:9b-q8_0

Um passo à frente em relação à quantização padrão: ele pelo menos criou um go.mod e um main.go. Mas então imediatamente travou, admitiu que precisava adicionar imports faltantes, tentou reescrever o arquivo inteiro usando um heredoc de shell — e falhou. O tempo de build foi de 1m 27s para algo que não funcionou.

Qwen 3 14b

Alucinação clássica sob pressão. Ele tentou buscar a documentação IndexNow três vezes seguidas, cada vez encontrando um 404 de uma URL errada (github.com/Bing/search-indexnow). Em vez de admitir que não conseguia encontrar nada, fabricou uma resposta com tom confiante — endpoint de API errado, método de autenticação errado. Quando o forcei a pesquisar novamente, ele produziu uma segunda resposta fabricada apontando para outra URL que também retornava 404. As informações que ele relatou estavam incorretas. Este é o modo de falha que mais quero evitar.

GPT-OSS 20b

Pelo menos o comportamento foi honesto e metodológico. Ele tentou uma longa cadeia de chamadas WebFetch — indexnow.org, vários repositórios do GitHub, páginas próprias do Bing — e encontrou 404s ou bloqueios do Cloudflare em quase tudo. Ele documentou cada falha de forma transparente. No final, ele ainda não conseguiu reunir informações suficientes para construir uma ferramenta funcional, mas, ao contrário do Qwen 3 14b, ele não inventou coisas. Apenas não conseguiu avançar.

GPT-OSS 20b (alto raciocínio)

Uma história significativamente diferente do modo padrão. Com o raciocínio alto ativado, o modelo se recuperou das mesmas buscas sem saída e conseguiu construir uma ferramenta completa e funcional — com parsing de flags apropriado (--file, --host, --key, --engines, --batch, --verbose), GET para URLs únicos e POST em lotes para múltiplos, conforme a especificação IndexNow.

Quando pedi documentação e testes de unidade, ele entregou ambos. Os testes passaram:

=== RUN   TestReadURLsFile
--- PASS: TestReadURLsFile (0.00s)
=== RUN   TestReadURLsNoProtocol
--- PASS: TestReadURLsNoProtocol (0.00s)
ok  	indexnow-cli	0.002s

Rápido também — build inicial em 22.5s. O raciocínio alto torna o gpt-oss:20b realmente utilizável.

qwen3-coder:30b

A falha mais interessante. Ele na verdade compilou e executou a ferramenta contra endpoints reais, viu erros reais de API voltando do Bing, Google e Yandex, e começou a corrigi-los:

Error notifying Bing: received status code 400 ... "The urlList field is required."
Error notifying Google: received status code 404 ...
Error notifying Yandex: received status code 422 ... "Url list has to be an array"

Isso é um bom instinto. O problema: ele estava rodando a 720% de CPU e apenas 7% de GPU — extremamente ineficiente para um modelo de 22 GB. Levou 11m 39s e a saída final ainda foi “não exatamente o que era esperado”. Ele também criou um README.md, que é um toque legal. Não é um modelo ruim, apenas muito lento na minha configuração e não acertou totalmente o formato do protocolo IndexNow.

qwen3.5:35b (Ollama)

Resultados sólidos, mas lentos. Ele criou um projeto Go apropriado, escreveu testes e todos passaram:

=== RUN   TestHashIndexNowPublicKey/non-empty_key
--- PASS
=== RUN   TestGetPublicKeyName/standard_root
--- PASS
=== RUN   TestGetPublicKeyName/custom_root
--- PASS

O lado negativo: tempo de build de 19m 11s. Para um modelo de 27 GB rodando com divisão 45%/55% CPU/GPU, isso é muito lento para uso interativo. A qualidade está lá, mas a latência mata o fluxo de trabalho.

Bigpicle (big-pickle)

O destaque para a primeira tarefa. Antes de escrever uma única linha de código, ele usou a Exa Code Search para pesquisar realmente o protocolo IndexNow:

◇ Exa Code Search "IndexNow protocol API endpoint how to notify search engines"

E ele encontrou os endpoints corretos:

• Global: https://api.indexnow.org/indexnow
• Bing: https://www.bing.com/indexnow
• Yandex: https://webmaster.yandex.com/indexnow
• Yep: https://indexnow.yep.com/indexnow
• Amazon: https://indexnow.amazonbot.amazon/indexnow

Ele resolveu o problema de importação do cobra de forma limpa (go mod tidy), e a ferramenta ficou pronta em 1m 17s. A resposta de limite de taxa que ele recebeu do Bing durante os testes foi realmente um comportamento esperado para uma chave de teste inválida — o modelo identificou corretamente isso como “a ferramenta está funcionando”. Impressionante.

devstral-small-2:24b

Confundiu-se em um nível básico: ele tentou escrever comandos de shell (go mod init indexnowcli, go mod tidy) diretamente no arquivo go.mod, gerando erros de parsing. De alguma forma, ele ainda conseguiu construir um binário (7.9M), mas o CLI resultante foi muito simples — apenas indexnowcli <url> <key> sem tratamento de flags, sem suporte a múltiplos motores, nada. Levou 2m 59s + 1m 28s para obter uma ferramenta que não era realmente útil.

qwen3.5:27b (llama.cpp, quantização IQ3_XXS)

Este foi o que mais me impressionou de todos os executáveis locais. Rodando como Qwen3.5-27B-UD-IQ3_XXS.gguf no llama.cpp (principalmente CPU), ele criou uma ferramenta completa com cobertura total de testes — todos os 8 testes passando — e um README apropriado com instruções de instalação e explicação do protocolo:

PASS    indexnow    0.003s

Motores suportados: Bing, Yandex, Mojeek, Search.io. Tempo de build: 1m 12s para a ferramenta, 1m 27s para testes e docs. Velocidade: 34 tokens/segundo. Qualidade: 5 estrelas. Resultado incrível para um modelo quantizado rodando em CPU+GPU.

qwen3.5:35b (llama.cpp, quantização IQ3_S)

Rodando como Qwen3.5-35B-A3B-UD-IQ3_S.gguf no llama.cpp. Minhas notas aqui são curtas: “excelente!” — o que diz tudo. O modelo maior no mesmo nível de quantização entregou resultados pelo menos tão bons quanto a variante de 27b, se não melhores.

Resultados do mapa de migração

Para a segunda tarefa, executei um lote separado — 7 modelos, todos recebendo as mesmas instruções, estrutura de site e lista de páginas. A restrição foi explícita: o slug (último segmento do caminho) deve permanecer o mesmo. Por exemplo, /post/2024/04/reinstall-linux/ deve se tornar /.../reinstall-linux/, não outra coisa.

Meça quantas incompatibilidades de slug cada modelo produziu — casos onde o slug de destino gerado diferia do slug de origem.

Modelo	Linhas	Incompatibilidades de slug	Taxa de erro
minimax-m2.5-free	80	4	5.0%
Nemotron 3	78	4	5.1%
Qwen 3.5 27b Q3_XXS (llama.cpp)	80	4	5.0%
Qwen 3.5 27b Q3_M (llama.cpp)	81	6	7.4%
Bigpicle	81	9	11.1%
mimo-v2-flash-free	80	42	52.5%
Qwen 3.5 35b IQ3_S -segunda execução (llama.cpp)	81	51	63.0%
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98.8%

Uma coisa que todos os 7 modelos fizeram de forma idêntica: URLs antigas no formato de 2022 tinham um prefixo de mês incorporado ao slug (ex: /post/2022/06-git-cheatsheet/ → slug 06-git-cheatsheet). Cada modelo removeu esse prefixo e usou git-cheatsheet como o novo slug. São 4 incompatibilidades consistentes nos três primeiros modelos — então sua linha de base é de 4 erros cada, não zero.

A verdadeira divergência começa acima dessa linha de base. minimax-m2.5-free, Nemotron 3 e Qwen 3.5 27b Q3_XXS só violaram a regra do slug naqueles 4 caminhos legados — nada mais. O Qwen 3.5 27b Q3_M adicionou 2 mais (renomeou o slug do artigo cognee e deixou em minúsculas Base64). Bigpicle adicionou 5 mais além dos 4, principalmente encurtando slongs longos.

Os valores atípicos estão em uma categoria diferente. O Qwen 3.5 35b IQ3_S reescreveu slugs consistentemente a partir dos títulos das páginas em vez de preservar a origem (ex: executable-as-a-service-in-linux → run-any-executable-as-a-service-in-linux, file-managers-for-linux-ubuntu → context-menu-in-file-managers-for-ubuntu-24). A segunda execução foi ligeiramente melhor (51 vs 59), mas mostrou o mesmo comportamento. Ele também alucinou um caminho de origem: mudou silenciosamente comparing-go-orms-gorm-ent-bun-sqlc para comparing-go-orms-gorm-ent-bun-sql (removeu o c), então ambos os lados daquela linha concordaram entre si — mas estavam ambos errados. mimov2 foi agressivo de forma semelhante ao encurtar: gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

A quantização IQ4_XS do 35b é uma categoria de falha totalmente diferente: 98.8% de incompatibilidades de slug — mas o problema não são slugs errados, é que o modelo esqueceu de incluir slugs completamente. Em vez de /new-section/page-slug/, ele produziu caminhos de categoria como /developer-tools/terminals-shell/ e /rag/architecture/. Oito páginas de origem acabaram mapeadas para /developer-tools/terminals-shell/ — todas apontando para o mesmo URL, o que seria catastrófico se usado. Apenas /developer-tools/ reuniu cinco páginas separadas. A saída é completamente inutilizável.

Para esta tarefa, o menor modelo quantizado Qwen 3.5 27b Q3_XXS igualou os melhores desempenhos — enquanto duas quantizações de 35b falharam gravemente, cada uma à sua maneira.

Conclusão

Estou feliz rodando tanto o Qwen 3.5 35b quanto o Qwen 3.5 27b localmente no llama.cpp com pesos quantizados — as restrições de hardware são reais (16GB VRAM significa quantizações IQ3/IQ4), mas o fluxo de trabalho é sólido.

O 27b Q3_XXS é o condutor diário confiável. Ele segue instruções com precisão, produz saída completa e é rápido o suficiente para uso interativo. Na tarefa de mapa de migração, ele igualou os melhores modelos em nuvem.

O 35b é capaz, mas imprevisível em tarefas estruturadas. Para codificação aberta — escreva-me uma ferramenta, construa isso — ele performa bem. Mas quando a tarefa tem regras estritas (como “o slug deve permanecer o mesmo”), ele alucina livremente em todas as quantizações que testei: reescrevendo slugs de títulos, removendo slugs completamente, até editando silenciosamente os caminhos de origem para fazer sua saída errada parecer autoconsistente. Se você usar o 35b para qualquer coisa que produza saída estruturada que planeja usar diretamente, construa uma etapa de validação em seu fluxo de trabalho. Não assuma que a saída está correta apenas porque parece plausível.

Se você está curioso sobre a velocidade com que esses LLMs performam, confira Melhores LLMs para Ollama em GPU 16GB VRAM.