O Ollama acabou de tornar possível o uso de seus modelos dentro do Claude Code.

Para testar as capacidades do Claude Code e comparar os principais modelos abertos com os fechados, comparei o GLM 4.7 e o Opus 4.5 em uma tarefa que exige atenção aos detalhes e habilidades de debugging.
O resumo é que o Opus 4.5 superou o GLM 4.7 por (o que considero) uma margem ampla. Isso faz o GLM 4.7 parecer inútil, mas não é.
Como o Ollama Tornou Isso Possível
A tarefa de fazer isso é mais tediosa do que difícil.
O Claude Code, como agente, apenas faz chamadas para os servidores da Anthropic para obter as respostas do modelo. Para fazer isso funcionar com qualquer outra API, trata-se de implementar um proxy que traduza as chamadas do Claude Code para a API de destino.

Não estou dizendo que esse trabalho não tem valor. Pelo contrário, é um ótimo trabalho que requer atenção e conhecimento de ambos os sistemas. Mas não é algo que apenas o Ollama poderia fazer. O claude-code-proxy fez a mesma coisa.
O Experimento
Venho usando o OpenCode e o Claude Code há algum tempo. Gosto da flexibilidade do OpenCode, e eles têm uma TUI muito ergonômica. Melhor que a do Claude Code, para ser honesto.
Mas o Claude Code sempre me deixou curioso. Sei que o Opus é um ótimo modelo, todo mundo que o testou para tarefas de codificação concorda com isso.
No entanto, eu tinha a ideia de que o Claude Code desempenhava um papel nessa superioridade. Agora que o Ollama tornou isso possível, é uma boa chance de testar o Agente isolado do modelo.
Então, decidi comparar o Opus 4.5 vs GLM 4.7 dentro do Claude Code.
Configurando o Claude Code com Ollama
Com a versão mais recente do Ollama, é muito simples configurar o Claude Code para usar modelos do Ollama. Você deve definir duas variáveis de ambiente: ANTHROPIC_BASE_URL e ANTHROPIC_AUTH_TOKEN.
A primeira deve apontar para o seu servidor Ollama local, geralmente http://localhost:11434/v1. A segunda pode ser qualquer coisa, na verdade.
O guia passo a passo é:
- Instale o Ollama
- Inicie o servidor Ollama com
ollama serve - Baixe o modelo que você deseja usar, ex:
ollama pull glm-4.7:cloud - Inicie o Claude Code com as variáveis de ambiente configuradas:
ANTHROPIC_BASE_URL=http://localhost:11434 ANTHROPIC_AUTH_TOKEN=ollama claude --model glm-4.7:cloud
Estou usando o GLM 4.7 da nuvem porque não tenho hardware suficiente para executá-lo localmente. Se você tiver uma GPU potente, pode executar o modelo GLM 4.7 Flash localmente.
A Tarefa
Há um equívoco comum. Como as pessoas tendem a usar Claude Code + modelos Claude, elas pensam que são a mesma coisa. Bem, não são. O Claude Code é apenas um frontend que faz chamadas para uma API que realiza a inferência de IA.
Isso significa que podemos ter qualquer API de backend com qualquer que seja o modelo. É uma questão de trocar o backend enquanto o torna compatível com o frontend.
Com isso em mente, decidi que queria ver o Claude Code sendo suportado pelo Gemini 3. Mas, claro, estamos em 2026, eu não queria escrever código.
Decidi que esta seria a tarefa perfeita para testar ambos os modelos:
Ollama just implemented an adapter for Claude Code
https://github.com/ollama/ollama/blob/main/anthropic/anthropic.go
It acts as a proxy, requests are sent to Ollama API instead of anthropic server.
I want you to implement a proxy like this to Vertex API, but it should be in Node.js.
Make direct calls as in the following curl. Don't install any library for calling Vertex api.
curl "https://aiplatform.googleapis.com/v1/publishers/google/models/gemini-3-pro-preview:streamGenerateContent?key=YOUR_API_KEY"
-X POST
-H "Content-Type: application/json"
-d '{
"contents": [
{
"role": "user",
"parts": [
{
"text": "Explain how AI works in a few words"
}
]
}
]
}'
I will provide the API key through CLI. It should get a server running. Claude Code will be pointed to it.Este é um prompt simples. Dou a referência para a implementação do Ollama, o curl para chamar a API do Vertex e eu apenas quero um servidor Node.js que atue como proxy.
Um bom resultado deve me entregar um servidor proxy funcional que consiga falar com o Claude Code. Não precisa ser perfeito, mas deve ser funcional.
Resultados
De erros de sintaxe a implementações erradas, ambos os modelos chegaram a uma solução funcional. Um deles, porém, foi muito mais eficaz.
Vamos ver a linha do tempo de ambas as tentativas, começando pelo GLM 4.7.
GLM 4.7
Eu dei o prompt e, um minuto depois, recebi uma implementação. Coloquei o servidor para rodar, sem erros de programação, mas o Claude Code não conseguia obter uma resposta do servidor. Enviei um “olá” para ele e não obtive resposta.
O próximo passo do agente foi fazer o debug. Ele adicionou logs de console (como todo bom desenvolvedor Node.js faz), e eu testei novamente.
As coisas estavam melhorando, uma resposta estava voltando para o Claude Code, mas era um erro da API do Vertex.
❯ API Error: 400 {"error":{"type":"api_error","message":"Vertex AI returned 400: [{n "error": {n "code": 400,n "message": "Invalid JSON payload received. Unknown name \"text\" at 'system_instruction.parts[0]': Proto field is not repeating, cannot start list.\nInvalid JSON payload received. Unknown name \"$schema\" at 'tools[0].function_declarations[0].parameters': Cannot find field.\nInvalid JSON payload received. Unknown name \"exclusiveMinimum\" at O problema foi encontrado, era devido a uma incompatibilidade entre o JSON enviado para a Anthropic e o esperado pela API do Vertex.
⏺ I see the issues. Vertex AI has two main problems:
1. System instruction format - The parts field structure is different for system instructions
2. Tool schema conversion - Anthropic uses full JSON Schema (with $schema, exclusiveMinimum, propertyNames) but Vertex AI only supports a subsetEle afirmou que estava corrigido, tentei novamente e recebi um erro 400 de novo. Eu quis ajudar, mas era difícil entender os logs. Havia informação demais. Ele estava imprimindo um payload JSON inteiro que era longo demais.
O modelo então “melhorou” isso truncando os logs. Ajudou. Pude ver que o proxy estava fazendo chamadas usando o nome do modelo errado. Ele deveria usar o nome do modelo que vem na requisição, não um nome fixo no código.
⏺ Done. The logging is now much cleaner:
- Truncates long strings (>200 chars) and large objects (>500 chars)
- Hides tool parameters and schema (just shows tool names)
- Simplified request logging (just shows method/path)
- Removed verbose debug logs for headers, body content, and Vertex candidatesO erro persistiu nas duas tentativas seguintes. Ele estava fazendo alguma substituição sobre o modelo que vinha na requisição. Não faço ideia do porquê.
Então sugeri que ele apenas usasse o modelo da requisição.
❯ theres no need to replace anything
just do this
const model = anthropicReq.model;Claude Code usa múltiplos modelos
O Claude Code faz múltiplas chamadas para modelos quando você interage com ele, e é inteligente o suficiente para rotear requisições para modelos diferentes quando necessário.
Como nos meus testes eu estava enviando um prompt simples de “olá”, ele estava usando um modelo menor para isso. Isso é ótimo, não há necessidade de usar um modelo grande e caro para tarefas simples.
Voltando ao GLM
Quebrou de novo. O proxy estava enviando requisições para o Vertex com o modelo nomeado claude-haiku-4-5-20251001.
Solicitei um mapeamento dos modelos Claude para os modelos Vertex. O ajuste fino continuou e, olhando os logs, eu tinha certeza de que tudo estava certo com a comunicação com o Vertex.
Infelizmente, o modelo não conseguiu descobrir por que eu não recebia resposta dentro do Claude Code.
Como última chance para o GLM, pedi que ele verificasse a implementação que o Opus tinha feito e visse se havia algo diferente.
Ele então corrigiu os problemas. Ainda recebi um erro relacionado à incompatibilidade do esquema JSON enviado ao Vertex. O modelo então comentou isso e enviou um payload mínimo para o Vertex.
Consegui obter uma resposta do Vertex dentro do Claude Code, mas não foi o que eu esperava. Era como se eu estivesse falando com o Gemini diretamente.

Ele não está incorporando as instruções de sistema do Claude Code. Era apenas um proxy para o Gemini.
Claude Opus 4.5
Você viu no primeiro experimento que o Opus foi capaz de implementar um proxy funcional. O código produzido foi, de fato, usado como referência para o GLM corrigir sua implementação.
Dei o prompt ao Opus e, um minuto depois, tive a primeira implementação. Também com alguns problemas como:
- modelo não sendo extraído da requisição;
- nenhuma resposta chegando ao Claude Code;
- endpoint errado sendo usado (generativelanguage.googleapis.com em vez de aiplatform.googleapis.com);
- incompatibilidade de esquema; claude-haiku sendo usado como nome do modelo;
- e um erro de sintaxe devido a um parêntese ausente.
Todos esses problemas eram semelhantes aos enfrentados pelo GLM. O Opus, porém, foi muito mais eficaz em corrigi-los.
Ele caiu na mesma situação que o GLM: nenhuma resposta chegando ao Claude Code. Passei os logs para ele e ele rapidamente entendeu o que estava acontecendo.
⏺ Now I see it. Vertex AI returns a JSON array [{...}, {...}] with pretty-printing, not SSE or newline-delimited JSON. I need to collect the full response then parse it.E funcionou como esperado. Recebi uma resposta do Vertex dentro do Claude Code.

Conclusão
Sim, o Claude Opus 4.5 é impressionante, e sim, ele superou o GLM 4.7 neste experimento. Mas não estou surpreso.
Algumas conclusões:
- Ambos os modelos enfrentaram problemas semelhantes. Está claro que o agente Claude Code tem uma maneira consistente de instigar os modelos e é muito bom nisso.
- O Opus 4.5 foi muito mais eficaz em superar os problemas. Exigiu menos interações para chegar a uma solução funcional.
- O Opus 4.5 é muito melhor em debugging. Essa habilidade, vital para desenvolvedores, também está presente no Opus (eu mesmo a usei para depurar alguns segmentation faults).
- O código do Opus 4.5 é mais limpo e mais idiomático.
Parece que o GLM 4.7 é inútil, mas isso não é verdade. Embora tenha tido dificuldades com esta tarefa específica de proxy entre protocolos, ele continua sendo um modelo altamente capaz para trabalho de desenvolvimento padrão. Para operações CRUD rotineiras, ajustes de CSS ou geração de boilerplate, o GLM 4.7 é mais que suficiente.
Além disso, se você tiver o hardware para executá-lo localmente, ele se torna uma ferramenta poderosa de redução de custos. Você pode delegar tarefas mais simples e de alto volume para sua instância local do GLM para economizar seus créditos da API do Claude para sessões de debugging complexas onde o Opus 4.5 seja necessário.
Não fiz outros experimentos com o GLM sobre esse assunto, mas teorizo que, se eu fornecer as especificações das chamadas do Claude Code, a API do Vertex e o comportamento esperado, ele poderia fazer um trabalho melhor.
O Claude Opus 4.5 pode ser a sua escolha para qualquer tarefa relacionada a codificação. É o modelo top 1 para codificação no momento. Também ouvi coisas ótimas sobre o GPT 5.2 com Codex.
Quanto aos modelos abertos, o GLM 4.7 é bem melhor que o Qwen3-Coder que testei anteriormente. Mas ainda não é suficiente para competir com modelos fechados em tarefas de codificação complexas.
We want to work with you. Check out our Services page!

