David Gewirtz relata que a combinação local de Qwen, Ollama e OpenCode concluiu um utilitário simples para renomear capturas de tela, mas não levou a um organizador de PDFs confiável. O resultado veio de tarefas específicas em um Mac Studio com M4 Max e 128 GB de memória; não é uma medida de desempenho para outros computadores ou projetos. Gewirtz descreveu o teste na ZDNET.
O que a configuração local conseguiu construir
No teste, Gewirtz usou o modelo qwen3-coder-next:q4_K_M com Ollama e OpenCode v2.2.5. O modelo era executado localmente, e a configuração usava um contexto de 64.000 tokens. Em termos simples, Qwen era o modelo, Ollama cuidava de executá-lo e OpenCode coordenava o agente de programação.
O utilitário concluído, chamado ScreenshotRename, abria uma pasta, exibia uma imagem por vez e permitia informar um novo nome de arquivo. Ao salvar, passava à imagem seguinte. Gewirtz relata que levou quase seis dias para terminar a ferramenta. Quatro deles foram consumidos por um problema na lista de arquivos, que ele acabou descartando antes de pedir a uma nova sessão do OpenCode que a refizesse.
A ferramenta cumpria a tarefa central, mas não tinha painéis redimensionáveis, modelos de nome ou data, zoom nem atalhos rápidos para avançar e voltar. Gewirtz diz que evitou acrescentar recursos que poderiam exigir mais depuração.
Por que o projeto de PDFs travou
Em outra tentativa, que durou cinco dias, Gewirtz trabalhou em um organizador de PDFs. O sistema conseguia identificar o assunto de um documento, mas não repetia a operação com confiabilidade em lotes grandes. A depuração esbarrou no subsistema de compreensão de documentos no dispositivo do macOS 27, que ele descreveu como novo e mal documentado.
A experiência aponta uma diferença prática entre montar uma ferramenta pequena e resolver problemas de depuração que exigem várias tentativas. Para suas tarefas, Gewirtz relata ter obtido melhores resultados mantendo os pedidos estreitos, iniciando sessões novas para correções ou funções isoladas e separando pesquisa de programação. Ele também exigia aprovação antes de ações no shell ou em arquivos.
Três caminhos para combinar agente e modelo
Uma alternativa local pode substituir o agente de programação, o modelo que ele usa ou ambos. Essa escolha muda o que permanece no fluxo de trabalho:
| Caminho | O que muda | Opções de execução descritas |
| Qwen, Ollama e OpenCode no teste | Substitui o modelo e o agente usados no fluxo | Modelo e agente executados localmente no computador do teste |
| Claude Code com Ollama | Mantém Claude Code e conecta modelos do Ollama | O tutorial de Eric Tech aborda o uso de modelos locais nessa configuração |
| Local-CLI | Usa uma CLI própria de agente com endpoints compatíveis com OpenAI | Endpoints locais, on-premises ou de nuvem |
O repositório atual do Local-CLI descreve uma CLI com licença MIT, requisito de Node.js 20 ou posterior, planejamento e execução em etapas e um modo supervisionado que pede aprovação antes de modificar arquivos. Para instalar a ferramenta, o repositório indica npm install -g local-cli-agent e, em seguida, local-cli; na primeira execução, um assistente configura o endpoint.
O projeto lista opções locais, como Ollama, vLLM e LM Studio, além de serviços em nuvem, como Azure OpenAI e Google Gemini. A afirmação de uso sem custo de API se refere a modelos locais ou on-premises, não a qualquer endpoint da lista.
Antes de trocar de agente, decida se você quer mudar o modelo, o ambiente que coordena a programação ou os dois.
Um tutorial em inglês de Eric Tech aborda a conexão entre Ollama e Claude Code; o criador caracteriza os modelos locais como mais lentos e não equivalentes diretos aos modelos em nuvem.
