Opus 4.7 vs GLM 5.1: misturar modelos vale a pena?

Há alguns meses, eu fiz um teste comparativo entre Opus e GLM. Não foi nenhuma surpresa que o Opus tenha se saído melhor.

Mas e se conseguíssemos que ambos trabalhassem em conjunto? Para fins de otimização: um planejando e o outro executando.

Já rodei essa comparação antes, mesmo plugin (cm-multilingual), três runs: Opus 4.7 sozinho, GLM 5.1 sozinho via Ollama Cloud, e GLM 5.1 seguindo o plano que o Opus tinha escrito. Era uma tarefa pequena – só dar feedback de progresso pra tradução IA – e o split "barato segue plano do caro" entregou ~99% do escopo do Opus por ~37% do custo.

Bonito demais. Numa task daquele tamanho não tem muita margem pra coisa dar errado, e eu sabia disso na hora que postei.

Mas é o tipo de resultado que vira thread no Twitter: "qualidade de Opus, preço de GLM/Qwen/Minimax/Kimi – é só passar o plano". Toda semana alguém posta uma variação – o modelo barato da vez muda, o argumento não. E era exatamente esse atalho que eu queria testar com mais rigor antes de adotar como default.

Daí eu subi a régua. Mesmo plugin, mesmo setup, só que agora a task era implementar tradução por chunks, melhorando a resiliência do processo inteiro, com a barra de progresso ainda em pé. Coordenação async entre PHP, REST, JS e um provider externo cuja latência pode ir embora no meio do caminho.

A resposta mudou. E é essa rodada que eu acho que vale a pena registrar.

Os três branches:

1. chunks-opus – Opus 4.7 planeja e executa.
2. chunks-glm – GLM 5.1 sozinho. Mesmo prompt verbatim. GLM planeja e executa.
3. chunks-glm-follow-opus – GLM 5.1 com o plano do Opus carregado no primeiro turn ("segue estritamente").

Todas passam nos testes. Todas funcionam, eventualmente. Mas pra responder vale a pena misturar? a forma como cada uma chegou lá é o que importa.

Nota metodológica: deixei cada agente trabalhar até a feature rodar e não iterei pra polir. Houve interações mínimas para garantir que todas as branches tivessem um entregável e só.

O que cada um entregou

Da perspectiva de UI, as três branches entregam praticamente a mesma coisa: barra de progresso na meta box "Translations", texto indicando o chunk atual. A diferença mora nas tripas – orchestrator, dispatch, testes – não na superfície.

Opus (chunks-opus). Refatora a tradução em três peças bem separadas: CM_Chunker (corta o post em pedaços por boundary de bloco HTML), CM_Translation_Orchestrator (recebe um ?callable $reporter no construtor e orquestra título -> chunks -> finalização), e o CM_REST_API continua só com o HTTP.

Dispatch paralelo de verdade via translate_batch que aceita um callback on_complete, disparado a cada chunk que retorna. A barra avança conforme as respostas chegam, em paralelo. Wall time ≈ max(latência por chunk).

GLM sozinho (chunks-glm). Sem orchestrator separado. ~150 linhas de orquestração inlinadas no handler REST.

Tem o CM_Chunker, mas o REST faz foreach sequencial sobre translate_with_context(), que envia o conteúdo do chunk. A barra avança chunk a chunk, mas wall time ≈ soma(latência por chunk).

GLM com plano do Opus (chunks-glm-follow-opus). Recria o orchestrator que o plano descreveu, mas sequencializa o dispatch (foreach chamando provider->translate( $chunk, ... )) com set_progress() antes de cada chamada.

Os números

Os três eixos onde o trade-off mais aparece. A tabela abaixo tem o resto do detalhe (tokens, autocompacts), mas as três métricas que importam pro veredito estão no gráfico.

Os custos em dólar são referenciais, é o que aquele volume de tokens custaria se você pagasse por API. Na prática, com a subscription Claude/Ollama Cloud o usuário paga zero por sessão – os números existem só pra comparar os três runs num eixo comum.

Algumas linhas dessa tabela merecem zoom.

Custo dolar: a economia continua existindo

$67.88 + $6.63 (plano) = $74.51 pro split mixed. Isso é ~41% do Opus sozinho. Bate com o ~37% que eu tinha medido na tarefa simples. A economia em billing é robusta entre as duas rodadas.

Se a única coisa que importa é "quanto isso custaria em retail", o split entrega o que prometia.

Tempo ativo: a economia some

Mas tempo ativo (o tempo que você fica acompanhando a sessão, descontados gaps idle de >90s) inverte:

• Opus: 46m 39s.
• GLM sozinho: 2h 9m 27s. ~2.8× mais.
• GLM com plano: 2h 41m 52s. ~3.5× mais – o pior dos três.

O agente seguindo plano de outro modelo gasta turns interpretando o plano, casando-o com a realidade do código, e voltando a perguntar quando a realidade não bate. Esperava que o plano encurtasse o run; em vez disso, ele alongou.

Supervisão: ~18 intervenções no run com plano

Esse foi o número que mais me incomodou. Contei "user check-ins corretivos" como mensagens do tipo "você validou de verdade?", "abre o browser de novo para garantir que funciona".

• Opus: 0.
• GLM sozinho: ~8.
• GLM com plano: ~18. Mais que o dobro do GLM free-form.

A intuição era que o plano reduziria a supervisão porque o agente teria menos liberdade de errar. Pelo contrário: as mesmas intervenções do GLM-livre apareceram no GLM-com-plano, só que mais cedo e em maior número.

Autocompacts: dois em cada run com GLM, zero no Opus

Autocompact é o Claude Code resumindo a conversa quando se aproxima do limite de contexto. Cada compaction substitui o histórico turn-a-turn por um summary lossy – a memória de trabalho do agente fica degradada.

• Opus: zero autocompacts. O caching da Anthropic mantém o prompt enxuto, então mesmo em 461 turns não bateu no teto.
• GLM sozinho: 2 autocompacts.
• GLM com plano: 2 autocompacts.

Como rodei cada cenário uma única vez, não dá pra dizer se o autocompact causou a degradação ou só a mediu – runs mais longos batem no limite mais fácil, e a mesma sessão que precisa de mais turns é a mais sujeita a compactar. Mas o sinal anda junto: zero autocompact, zero check-in corretivo, run curto. Dois autocompacts, várias intervenções, run longo.

Validação assistida saiu da mesa com o GLM

O chrome-devtools-mcp foi central pra esse experimento – agente clica no botão, espera a tradução, lê o DOM, valida a feature sem eu precisar abrir o browser. Funcionou bonito com Opus: o run inteiro de validação rolou agent-driven, eu só assistia.

Com GLM rodando via Ollama Cloud, não foi possível.

O MCP em si responde rápido (snapshot, screenshot, evaluate_script ficam dentro do ruído). Mas as chamadas que esperam o browser terminar de fazer alguma coisa (wait_for, navigate_page) ficaram impraticáveis: wait_for 3.8× mais lento, navigate_page 27× mais lento, com max de 199.8s numa única chamada. Total dos roundtrips chrome-devtools: 110s no Opus, 559s no GLM.

A causa não é o MCP, é o que o browser estava esperando. Quando o agente manda o browser clicar em "Translate with AI" e dá wait_for, o que ele tá esperando é o backend chamar o Ollama Cloud, que é a mesma latência do GLM em si. A lentidão do modelo vaza pra dentro do loop de validação e estraga a UX assistida.

Vale registrar que isso não é peculiaridade do meu setup. A própria comunidade tem reportado degradação no serving do Ollama Cloud nos últimos meses, exemplo: r/ollama: "Ollama cloud has become unbearably slow".

Em condições melhores de serving o gap de tempo ativo encolheria. No entanto, o resto do que o post mede (supervisão, DX de validação) é da execução do modelo em si e não muda.

Fiz QA manual nas duas branches GLM. Eu mesmo abri o post, cliquei no botão, monitorei a barra, fiz o request com posts longos do meu instance.

É o que vira "GLM precisa de mais supervisão" na contagem de check-ins. Boa parte das ~8 (free-form) e ~18 (com plano) intervenções é exatamente isso: eu assumindo o trabalho que o agente não conseguia fazer agent-driven.

Não é que o GLM se recusou a validar. É que, com a latência do Ollama Cloud, deixar ele validar end-to-end teria multiplicado o wall-clock por mais um fator.

Qualidade de código (rápido)

Três eixos onde a diferença vale o zoom:

• Encapsulamento.
  Opus separa orchestrator, chunker e REST em arquivos próprios. O orchestrator não conhece WordPress: o construtor recebe ?callable $reporter e o método report() só chama o callback. Quem decide o que fazer com o evento (escrever transient, logar, mandar pra outro lugar) é o REST. Inversão de dependência limpa.

  GLM-com-plano também separa orchestrator, mas armazena $post_id e $target_lang_code como propriedades mutáveis da classe. Setadas no início de translate_post(), lidas dentro de set_progress() que chama set_transient() direto. Acopla o orchestrator ao WordPress e à identidade (post, lang). Não dá pra reusar a classe num contexto sem transient.

  GLM sozinho não tem orchestrator. ~150 linhas de orquestração inlinadas no handler REST, bem do meio do arquivo. Misturado com lock/transient/get_active_provider/copy_taxonomies no mesmo método.

• Testes adicionados (todos os arquivos).

  Total bruto: Opus 85 testes / 194 assertions em 5 arquivos, GLM-sozinho 76 / 171 em 4 arquivos, GLM-com-plano 69 / 145 em 5 arquivos. GLM-com-plano é o que adicionou menos cobertura, em todos os recortes. Opus é o que adicionou mais.

  Bruto não conta tudo. Olhando por dimensão:

  • Contrato da feature nova. Opus pinou o on_complete callback do translate_batch em 6 testes dedicados no Test_CM_Providers (test_translate_batch_on_complete_fires_for_each_chunk_via_pre_filter, ..._for_single_text_path, ..._for_build_time_errors, etc.). Esse callback é o que faz a barra avançar ao vivo, e está garantido em teste.

  GLM-sozinho tem 3 testes de translate_chunks (cobrem dispatch básico, sem afirmar nada sobre callback porque não tem callback). GLM-com-plano tem 0 testes do contrato paralelo porque também acabou não usando paralelo.

  Em outras palavras: cada implementação testou exatamente o que ela escolheu fazer. O problema é que as duas GLM-runs escolheram um caminho menos exigente, o que significa menos teste pinando comportamento.

  • Endpoint de progresso. Os três runs testam o endpoint REST de progresso, mas com profundidade diferente. Opus checa estado idle (test_progress_returns_idle_when_no_translation_in_progress), isolamento de chave por par (post, lang) (test_progress_keys_are_isolated_per_post_and_language) e a permissão edit_posts (test_progress_endpoint_requires_edit_posts_capability). GLM-sozinho testa o caminho feliz e um not-found, mas não testa autenticação nem isolamento. GLM-com-plano fica entre os dois.

  • Round-trip do chunker. Os três têm um teste de reassembly (test_reassembly_preserves_byte_for_byte_equality no Opus, test_reassembly_matches_original no GLM, test_preserves_content_through_chunk_and_reassemble no GLM-com-plano). Nivelado nesse recorte. Diferença sutil: o Opus exige byte-for-byte, os outros aceitam "matches" – uma é invariante exata, a outra deixa espaço pra interpretação.

  • Edge cases. Opus testa oversized_single_block_is_emitted_unsplit, placeholder_token_is_never_split_internally, e (no Test_CM_Meta_Box) 14 testes incluindo meta_box_is_not_registered_when_block_editor_active – o caso que historicamente quebrou em produção. As duas GLM-runs param em 12 testes de Meta_Box e não cobrem essa transição.

  Dois sub-detalhes que merecem nota:

  GLM-sozinho tem 34 testes no Test_CM_Providers (mais que o Opus, 30) mas com 72 assertions vs. 55 do Opus. Em média mais raso por teste; muitos são variações próximas (test_translate_chunks_with_single_chunk_calls_translate, ..._with_multiple_chunks, ..._returns_error_on_provider_failure) onde um @dataProvider resolveria. Volume ≠ profundidade.

  GLM-com-plano também tem o menor assertions/teste médio entre os três (~2.1), o que sugere testes "bate na superfície" mais que "interroga estado".

• Estratégia de dispatch.
  Opus: paralelo de verdade, via translate_batch( $chunks, …, $on_complete ) que dispara as N requisições simultâneas e fecha cada uma via callback assim que ela responde. Wall time ≈ max(latência por chunk). A barra acompanha a chegada das respostas.

  Os dois GLM-runs convergiram pra dispatch sequencial com payload enxuto (foreach que chama provider->translate( $chunk, ... )). A barra avança chunk a chunk, mas wall time ≈ soma(latência por chunk) em vez de max. Pra um post de 8 chunks, isso é a diferença entre "2 minutos" e "16 minutos" – mesma feature aparente, custo de espera muito diferente.

  Detalhe sobre o GLM-com-plano: o comentário no próprio código documenta a escolha – "Translate chunks sequentially so progress updates are visible". O autor preferiu progresso visível a wall-clock menor.

  É uma escolha defensável (ver progresso > esperar mais rápido). Mas é interessante que o plano do Opus descrevia o paralelo via callback, e o agente preferiu não seguir essa parte.

Em resumo: Opus > GLM-com-plano > GLM-sozinho em encapsulamento e testes; e Opus na frente das duas GLM-runs em dispatch (paralelo vs sequencial). Ou seja, cada eixo conta uma versão da mesma história, que é o quanto o autor pensou no consumidor da classe (encapsulamento), no manutentor (testes do contrato), e no usuário final esperando a barra (dispatch).

O que esse post não é

Antes de fechar, quatro ressalvas pra calibrar como você lê os números acima:

• Não é paper, é anedota informada. Rodei cada configuração uma vez, em horários diferentes (latência da Ollama Cloud varia bastante de manhã pra tarde), sem fixar seed. Os números servem como sinal, não como benchmark estatístico.

  Pra quem quer o benchmark estruturado da mesma pergunta – rodadas repetidas, mais modelos comparados, métrica de qualidade – o Akita publicou semana passada exatamente isso: Vale a pena misturar 2 modelos?. A conclusão dele bate com a minha. Esse post aqui é o sinal anedótico do mesmo achado, em cima de plugin real em vez de Rails greenfield.

• Roda tudo no Claude Code. É o agente que uso todo dia, é nele que confio meu workflow. Não testei em Cursor, Aider, Windsurf, ou outro harness – algumas observações sobre supervisão e DX podem ser específicas desse ambiente em particular.

• Conflito de interesse implícito. Claude Code é da Anthropic, e os modelos Opus provavelmente são otimizados pra esse harness. Não dá pra separar com certeza "Opus é melhor" de "Opus encaixa melhor no Claude Code". Eu acredito que o gap se mantém em outro harness, mas não posso provar com esse experimento.

• Não é torcida pelo Opus. Toda vez que a Anthropic tem outage, eu mudo pra GLM 5.1 via Ollama Cloud sem pensar duas vezes.

  É genuinamente o segundo melhor par modelo/harness na minha rotina, e é o que paga as contas quando o primeiro está fora do ar. Esse post não é "GLM ruim". É "split com plano não compensa quando o problema cresce".

Um detalhe que provavelmente puxa o gap pra cima

Vale registrar uma coisa antes do veredito: transient + polling foi escolha minha como mantenedor do plugin, não algo que os agentes tiveram que decidir. Eu queria a coisa mais simples e efetiva por enquanto pra esse caso.

O que isso faz com o experimento: ele não testou capacidade de arquitetar coisa difícil. Não tem SSE, não tem WebSocket, não tem Action Scheduler com fila e push do servidor pro cliente, nada disso.

Ainda assim, se o resultado já mostra Opus 47m vs. GLM-com-plano 2h42m + ~18 intervenções corretivas + DX de validação completamente manual nesse setup simples, é razoável esperar que o gap se alargasse num cenário onde a arquitetura ela mesma fosse parte do desafio. Aqui, o agente só tinha que costurar bem o pattern padrão.

Vale a pena misturar?

Portanto, a resposta direta pra essa rodada: não compensou.

As três branches entregaram código que funciona – mesma feature, mesma baseline. O que mudou em torno foi tudo o resto:

• 41% do custo em dólar (a economia de billing aguenta)
• 3.5× mais tempo ativo que o Opus, e pior que o GLM free-form
• ~18 intervenções corretivas vs. ~8 no GLM free-form vs. 0 no Opus
• DX de validação que sai de "agente dirige o browser e eu assisto" (Opus) pra "eu mesmo abro o post, clico, monitoro" (qualquer GLM)

Se seu tempo na frente do teclado vale qualquer coisa acima de zero, a conta inverte. A 60 USD/hora, GLM-com-plano já fica mais caro que o Opus sozinho. A 100/hora, Opus ganha por uma margem confortável.

E, mais importante que o número: essa tarefa envolve coordenação async entre PHP, REST, JS e um provider externo cuja latência pode ir embora. Nesse tipo de problema, o plano que você passa pro executor barato tem que ser muito bom pra fechar a lacuna de execução. O do Opus era bom – e mesmo assim não fechou.

Em quais situações o split ainda faz sentido: task de UI razoavelmente delimitada, com escopo bem claro. Basicamente o cenário simples do experimento original: sem chunking, sem coord async, sem timeout brigando com você. Aí o plano fecha a lacuna e o executor barato cumpre.

Pra qualquer coisa que mexa com timing, paralelismo, ou dependência externa, faz o Opus sozinho. Você paga pelo "não precisar babysittear", não pelos tokens.

E pra bugfix em código que você conhece bem, GLM sozinho serve: o plano já mora na sua cabeça.

Não estou dizendo que split nunca compensa. Estou dizendo: quanto mais complexo o problema, menos o plano-pré-pronto compõe com o executor barato. O plano fecha a lacuna de O-QUÊ. Deixa aberta a lacuna de COMO. E o COMO é onde o tempo extra, a supervisão extra e a DX degradada aparecem.

Cuidado com o atalho universal

Você acabou de fazer a conta inteira comigo. Se daqui a pouco te aparecer um thread no Twitter/X prometendo "qualidade de Opus, preço de GLM/Qwen/Minimax/Kimi – é só passar o plano", ele tá te mostrando uma coluna do CSV. A outra metade não está no billing.

E não é só esse experimento aqui dizendo isso. O Akita rodou um benchmark multi-modelo mais amplo no mesmo mês, com três harnesses e sete combinações de modelo, e chegou na mesma resposta: solo Opus pra greenfield típico, multi-modelo só compensa em tasks genuinamente paralelas e desacopladas. Métodos diferentes, conclusão alinhada.

Eu vou mergear a chunks-opus no plugin. As outras duas branches ficam como referência: a free-form é o mínimo viável que o GLM entrega num prompt raso, e a com-plano mostra como é caro tentar fechar a lacuna de capacidade com plano. Nenhuma das duas vai pro main.

O próximo passo é implementar a feature da maneira mais ideal (SSE, scheduler) e observar GLM e outros modelos como Minimax e Kimi K2.6 trabalhando nelas.

Em três linhas, pra quem chegou aqui pelo final:

• Split funciona em tarefa simples e bem delimitada – o plano fecha a lacuna do executor barato.
• Em tarefa complexa, o COMO escapa do plano. Tempo extra, supervisão extra e DX degradada viram a conta – e essa conta não está no billing.
• Você paga o modelo caro pelo "não precisar babysittear", não pelos tokens.

Por hoje é só.

Os agregados por sessão estão neste gist: token counts, tempo ativo, breakdowns de ferramenta, transcripts dos check-ins corretivos, comparação completa entre as três sessões.

Se quiser conferir os números do post ou discordar das conclusões, é o ponto de partida.

We want to work with you. Check out our Services page!